Access, like Paradox, *will* corrupt the data at some point because it's
fundamental operation is based on shared files. Single, or minimally
overlapping, Access databases are pretty stable in my experience but I've
always instituted a regular "backup-repair-compact" regime. I also know of
some very large (100s of Mb), multiuser, Access apps that are very stable -
but they've spent literally years fine-tuning them to avoid the inevitable
corruption - which they do still get (then it's 2-3 hrs before it's
repaired, compacted and up again).
I'd be very wary of trying to achieve either of the above from NZ if you
don't have knowledgeable feet on the ground. As well as the multi-user
aspect I'd be asking about things like the stability of the power supply
etc. An unstable environment will definitely corrupt Access files, any
Client-Server backend, and IB in particular, is far more robust than any
Shared-File database. IB of course shouldn't need an upgrade path - size
barely matters, concurrent power-users does.
It all depends on the individual case - but I've yet to see a cost-benefit
for a mission critical system where the risk of lost data/uptime outweighs
the cost of a small IB deployment.
Max
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Simon Mahony
Sent: Tuesday, 2 March 1999 17:06
To: Multiple recipients of list delphi
Subject: [DUG]: Access vs Interbase/SQL Server
We're putting together a mission critical system for deployment to Asia.
I've almost convinced my boss to deploy Interbase as the database engine,
but the other two members of my team have come forward with a preference
for
using MS Access instead.
What I need is some real-life stories of deploying and using Access which
highlight the pros and cons of doing so.
If Access is the right solution for this situation then I don't want to get
in the way just because I have a better feeling about another product, but
if it's going to be a real problem then I need at least some anecdotal
evidence to back up my position.
SITUATION:
We'll be deploying a weather information system to Asia. It will have to be
managed from here since we have no support on the ground up there. The main
table in the DB will contain about 5000 records which will be totally
replaced DAILY over the course of the day as new information becomes
available. Other less volatile operational data will make up the rest of
the
database (about ten to fifteen tables in all).
We may want a scalable solution (management think "probably not" but...),
but I'm not very keen on choosing Access just to provide an upgrade path to
SQL Server, since I've heard nothing to make me feel optimistic about this
process.
I'm told we won't be neding a multi-user system as such, but since our app.
will consist of several independant Exe.s and a Report Writer which need to
talk to the DBMS, we'll have at least two or three connections running
simultaneously.
The main problems we face are:
1) relatively high data throughput.
2) long distance for support and DB maintenance
3) use of a report writer (probably Crystal) for very complex output.
4) DBMS must handle almost simultaneous data insertion, general queries,
and
reporting*.
*We will be deleting records as they become out-of-date. There will be very
little updating as the data is either valid or obsolete.
If anyone has any experiences to relate, I'd really appreciate hearing them
:-)
Simon Mahony,
System Creator,
MetService.
email: [EMAIL PROTECTED]
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
