RE: [DUG]: Access vs Interbase/SQL Server
Do you mean TClientDataSet ? I can't find TDBClient on the palette. Cheers, Simon. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Goodrich Sent: Thursday, 4 March 1999 02:20 To: Multiple recipients of list delphi Subject: Re: [DUG]: Access vs Interbase/SQL Server If your applications database is so small, why don't you use TDbClient. I have found these faster and infinitely more reliable than any of the alternatives for small systems. regards tony goodrich -- - 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
RE: [DUG]: Access vs Interbase/SQL Server
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
Re: [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. Okay. I use MS Access a LOT as a client (usually to Oracle). I would hesitate though to use it mission critical situation. I cant comment whether IB is better though. Are you taking Access as a "server" with a Delphi via Jet/ODBC as the client? or just What I need is some real-life stories of deploying and using Access which highlight the pros and cons of doing so. 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). 5000 records is fine for Access. It seems to run out of steam at around 100,000 in my experience (memory dependent). Multiuser write access has all kind of hassles, but it seems you mightnt need this. Let me know if you want more on what happens and how to improve things. Your biggest issue here will be fragmentation of the database. They will need to compact the database periodically. Access doesnt do this by itself. 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. If your application isnt written for server in first place, then scaling up is always a pain. If Access is also the client, then need to develop VERY carefully to give any hope. Better still, if Access is client, then develop it was SQL server or IB whatever in first place and DOWNSIZE it to a separate access database. 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. Probably okay. Multiple writers are a problem. Access databases corrupt easily for reasons I have never been clear about. The repair function often fixes everything though, but that is manual intervention. Good backup is pretty essential. If you have multiuser access clients, then I have more war stories. -- Phil Scadden, Institute of Geological and Nuclear Sciences PO Box 30368, Lower Hutt, New Zealand Ph +64 4 5704821, fax +64 4 5704603 --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
Re: [DUG]: Access vs Interbase/SQL Server
The basic rule with this decison (I have found) is that if you don't write it multiuser/client-server now, then it won't happen at all - not without a rewrite anyway. Good C/S development requires time to learn and trying to adapt a single user app/database to a multiuser environment is never going to work without a rewrite. So, choosing Access - which as everyone knows is useless beyond 5 - 10 users - will lock you forever with 5 - 10 users. Similar arguments could be used with Paradox or any other file based system. --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
