[DUG] List working?

Thu Mar 16 16:14:20 NZDT 2006

QUOTE FROM

http://support.microsoft.com/?scid=kb;en-us;303528

Additional best practices for network environments

Microsoft Jet is a file-sharing database system. A file-sharing database
system means that the processing of the file occurs at the client. When a
file-sharing database, such as Microsoft Jet, is used in a multi-user
environment, multiple client processes use file read, file write, and file
locking operations on the same shared file across a network. If a process
cannot be completed, the file may be left in an incomplete state or in a
corrupted state. A process may not be completed for either of the following
reasons: 

.

When a client is stopped unexpectedly

.

When a network connection to a server is dropped

Microsoft Jet is not intended for use with high-stress server applications,
high-concurrency server applications, or 24 hours a day, seven days a week
server applications. This includes server applications, such as Web
applications, commerce applications, transactional applications, and
messaging server applications. For these types of applications, the best
solution is to switch to a true client/server-based database system, such as
Microsoft Data Engine (MSDE) or Microsoft SQL Server. When you use Microsoft
Jet in high-stress applications such as Microsoft Internet Information
Server (IIS), you may experience any one of the following problems: 

.

Database corruption

.

Stability issues, such as IIS crashing or locking up

.

Sudden failure or persistent failure of the driver to connect to a valid
database that requires re-starting the IIS service

The following sections contain recommendations to follow when you share a
Microsoft Jet or a Microsoft Access database file on a network file server.

-----Original Message-----
From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz] On
Behalf Of Matthew Comb
Sent: Thursday, 16 March 2006 4:09 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: RE: [DUG] List working?

I've always felt like Access was like a multithreaded server without

critical sections.

With one user you will have absolutely no problems. With few users its

highly unlikely that the threads will clash.

With more users, it turns to a pile of crap, which can be addressed by

having keepalives (rebuild mechanisms on startups and around the posting

routines etc).

But seriously. I can't accept that people would actually push access as a

serious contender for multi user environments.

I mean sure I could wash my clothes in the bath, but it doesn't make it a

dual purpose washing machine,

and if i was going to  ride up a mountain, I could surely do it on a bike,

but it would be a hell of a lot easier in a 4 wheel drive. Especially one

strong enough to protect me from crazy random people on bikes descending

down the mountain...

> Well if we are talking a small multiuser system then it does have some

> advantages. In my view those advantages are more than outweighed by the

> potential for data corruption anytime a client freezes or disconnects from

> the network, not to mention lack of Stored Procs etc (at least in the

> version I used). That's why we use MSDE/SQL Server instead now.

> 

> However that doesn't mean everyone would come to the same conclusion I

> did.

> For some people Access's advantages might be godsends. For example, I have

> my doubts that our Christchurch customer is using the same server box that

> they were using 8 years ago (they might be but it seems unlikely). That

> means they have probably moved the database on their own without support.

> With Access moving the database just means moving the mdb file and

> creating

> a new network share. I doubt they would have been able to move an MSDE

> database without our help. Similarly backing up MSDE requires either

> special

> backup software or running a script to backup the data/log files to disk

> and

> then to your backup destination. Backing up Access is a simple matter of

> copying a file.

> 

> Access is also blindingly fast at accessing data which isn't changing.

> Once

> data has been cached locally it becomes near impossible for a proper

> server

> based database to compete in pure read speed terms. Of course if the data

> being accessed is constantly changing then the situation reverses, etc.

> 

> Just because most serious developers value the functionality of a server

> based database more than the functionality Access provides doesn't mean

> that

> it is a completely useless product.

> 

> All IMO of course. And should be taken with a grain of salt as I haven't

> used Access for development since 1998...

> 

> David.

> 

> 

> 

> -----Original Message-----

> From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz]

> On

> Behalf Of Neven MacEwan

> Sent: Thursday, 16 March 2006 3:45 p.m.

> To: NZ Borland Developers Group - Delphi List

> Subject: Re: [DUG] List working?

> 

> David

> 

> In my opinion a software product that doesn't meet very high reliability

>   levels in its designers intended use is a poor product, If you are

> prepared to state that Access is a very reliable platform in multiuser

> environments I'd be interested, otherwise you might as well suggest a

> person with a stutter makes a very good news reader providing you listen

> carefully

> 

> Neven

> 

> David Brennan wrote:

>> We have a customer in Christchurch who has been running an old VB4

>> version

>> of our software with multiple client machines connecting to an Access

>> 2.0

>> (32 bit) database. They have been running the software for about 7 or 8

>> years.

>> 

>> We tend to forget they are there... because they have never once called

> with

>> a problem of any sort.

>> 

>> Not saying you are going to be that lucky every time and part of the

> reason

>> we don't hear from them may be that the program has startup code for

>> attempting auto-recovery from corrupted databases. But Access <can> be

>> surprisingly fast and reliable.

>> 

>> David.

>> 

>> 

>> -----Original Message-----

>> From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz]

> On

>> Behalf Of Neven MacEwan

>> Sent: Thursday, 16 March 2006 3:16 p.m.

>> To: NZ Borland Developers Group - Delphi List

>> Subject: Re: [DUG] List working?

>> 

>> Don't be dim James are you saying that Access is not intended for DB

>> applications, The assertion that its ok  and was designed for "single

>> user desktop style" apps and not anything more is crap if it wasn't

>> intended for " multi user environment" then it shouldn'd effing well

>> support it (badly or otherwise) should it?

>> 

>> Neven

>> 

>> James Sugrue wrote:

>>> The problem isn't with Access, the problem is people using Access for

>> things

>>> it's not really intended for.

>>> Access is fine - and I use it all the time - for single user desktop

> style

>>> applications. It's when it gets used in a multi user environment things

>> can

>>> be a problem, especially when combined with bad design or programming.

>>> 

>>> 

>>> -----Original Message-----

>>> From: delphi-bounces at ns3.123.co.nz

>>> [mailto:delphi-bounces at ns3.123.co.nz]

>> On

>>> Behalf Of Maurice Butler

>>> Sent: Thursday, 16 March 2006 8:28 a.m.

>>> To: 'NZ Borland Developers Group - Delphi List'

>>> Subject: RE: [DUG] List working?

>>> 

>>> Hi,

>>> If you want to know how bad Mickysoft Access is ask any school that

>>> runs

>>> musac - this is a student manager program that spends more time being

>> fixed

>>> than used.

>>> If you want sql, mdse is alright for small apps that need sql &

>>> Mickysoft

>>> compatablity.

>>> 

>>> Maurice

>>> 

>>> 

>>> 

>>> _______________________________________________

>>> Delphi mailing list

>>> Delphi at ns3.123.co.nz

>>> http://ns3.123.co.nz/mailman/listinfo/delphi

>>> 

>>> 

>> 

> 

> --

> Neven MacEwan (B.E. E&E)

> Ph. 09 620 1356 Mob. 027 4749 062

> 

> New Address Details

> ===================

> MWK Computer Systems

> 1 Taumata Rd

> Sandringham

> Auckland

> 

> Ph 620 1356

> Fx 620 1336

> 

> _______________________________________________

> Delphi mailing list

> Delphi at ns3.123.co.nz

> http://ns3.123.co.nz/mailman/listinfo/delphi

> 

_______________________________________________

Delphi mailing list

Delphi at ns3.123.co.nz

http://ns3.123.co.nz/mailman/listinfo/delphi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns3.123.co.nz/pipermail/delphi/attachments/20060316/8d80f2e0/attachment-0001.html