*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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED]
> 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
>> [email protected]
>> 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
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
------------------------------------------------------------------------
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
