[Date Prev][Date Next][Thread Prev][Thread Next]
[Author Index]
[Date Index]
[Thread Index]
[SQR-USERS Info]
[SQRUG Home Page]
RE: [sqr-users] SQR Front-end
Second that. Access is _NOT_ a network application.
Richard Knapp
Database Programmer/Analyst
Institutional Research and Planning
University of Missouri System
573-882-8856
knappr@umsystem.edu
-----Original Message-----
From: apthornton@nisource.com [mailto:apthornton@nisource.com]
Sent: Thursday, May 22, 2003 9:12 AM
To: sqr-users@sqrug.org
Subject: Re: [sqr-users] SQR Front-end
I have maintained several MS-Access based systems in the past, and have
found several different types of systems that Access works well for:
* Transitory systems or temporary systems used by few individuals
* Database systems that must run stand-alone on Non-network-connected
PCs. (Such as field employees)
* Systems that are used by only one person that have thousands of
rows of data and a simple interface.
I have noticed the problems with Access in multi-user network
configurations:
* Poor network performance when accessed from a remote server
* Backup software not recognizing the changes to the file.
* Record locks (and .ldb lock files) not releasing after an ABEND on
a user PC.
* Difficulty auditing application.
* Poor performance with larger data sets (greater than 20-30K rows)
or joins, compared to other database systems
Basically, if you have more than one person using the system, or more than
tens of thousands of rows, or need the system to be robust and constantly
available, I would highly recommend SQL Server or Oracle, dependant on the
system's size. (I have not had experience with MySQL, but have heard good
things about it.) We normally use SQL Server for databases up to a hundred
thousand rows or so, and Oracle until it's too large for the Client-Server
arena. Visual Basic makes a good front-end tool for ODBC databases.
If you do go with Access, I would either go with a web-based ((d)HTML/ASP)
application or with the internal Visual Basic for Applications (Access)
languages. (Having ODBC connections to Access can get to be rather
problematic, especially when there is more than one person using the
application.) If you want to segment the data and the presentation (this
is a VERY GOOD THING to do), then you can use table links from your front
end database to your back end database.
(I made a living coding Access databases for several years, and it is a
wonderful tool for some jobs. It is a tool that is good for what it is
good for, and a poor substitute for other tools when used in places where
it doesn't belong. Access is kind of like a hammer.... there's no tool
better for driving nails, but it does a poor job with screws.)
Allen
"Mark Sanford"
<marksanford@att To: <sqr-users@sqrug.org>
bi.com> cc:
Sent by: Subject: [sqr-users] SQR
Front-end
sqr-users-admin@
sqrug.org
05/21/2003 06:39
PM
Please respond
to sqr-users
Hi Folks!
I have a client that has a 20+ year old PC-Cobol system. The client was
wondering if I could bringthem into Windows.
I have been working with SQR (and enjoy it), so I was wondering if I could
bring write some SQRs that migrated them (the client) to an Access
database.
I would like to build them a front-end for the SQR converted application,
but was wondering what you (the SQR Users Group) might suggest for a
Windows-front end (VB, Access, Delphi) for an SQR-based system. SQR will
have to be able to communicate (ODBC) with the database platform chosen.
I appreciate any and all advice.
Thank you,
Mark Sanford
_______________________________________________
sqr-users mailing list
sqr-users@sqrug.org
http://www.sqrug.org/mailman/listinfo/sqr-users
_______________________________________________
sqr-users mailing list
sqr-users@sqrug.org
http://www.sqrug.org/mailman/listinfo/sqr-users
_______________________________________________
sqr-users mailing list
sqr-users@sqrug.org
http://www.sqrug.org/mailman/listinfo/sqr-users