Slow Performance on WIN NT/XP/2K Shares

1) Does VB6 SP5 update the MDAC?

2) When you are the last user to close the app, Jet attempts
to Delete the LDB file(s).

It will not be able to delete the LDB file if it is in use.
Depending on your OS and network, you may have to wait for a
time-out when you attempt to delete the file, and you may attempt
to delete the file several times.
Even if the LDB file is not in use, the Server OS may not release
it until after a delay (a basic server optimisation is to delay
closing a file, in case it is re-opened immediately).

You are especially likely to have problems when closing if
(a) the Ldb file is not in use, and
(b) the server has held it open for another user

Jet will know that you were the last user, and attempt to
delete the LDB file: the server won't let you.

You may have problems even if you are a single user:
(a) You were the last user
(b) the LDB file is no longer in use
(c) the server has held the file open for you, because
it thinks you might want to use the file again.

A simple 'solution' is to always leave the database open:
you could run some process on the server (or on a workstation)
that holds the database open.

Another thing you can try is turning off file caching
(on the server, or just for that specific file on the server)

And generally, you can set the server so that it is
optimised for network traffic, rather than as a file
server. (And if you see the option, Don't consolidate
network packets).

However, your problem is slightly unusual: I don't think
that correctly patched versions of Windows, VB6, JET, and
DAO/ADO should have the problem you describe.

(david)

PS: as a matter of language, you do have a client/server
Architecture: a File Server, and a Network Client. Don't
think that the client/server optimisations are not important
just because your development tool hides them from you.

"Martin Aalders" <maalders.DeleteThis@frey.de> wrote in message
news:effODOg2DHA.1740@TK2MSFTNGP12.phx.gbl...
 > In an VD6 Application we use mdb shared Files which are placed on a Server
 > Share and are opend simultaniously by about 5 Users, usally Read only. We
 > use DAO 3.51. Erverything worked fine for years, but now, since we
 > installed some Service Packs (VB6 SP5), accessing the mdb Files ist
 > extremely slow, especially closing the App (which closes the MDB Files) is
a
 > mess (> 30 Seconds) when there is more than one user that has the MDB
still
 > oben. This only happes, when the File Server is NT based: W2Kpro,
W2KServer,
 > W2003 Server, WXPPro. Everything ist fast and OK when the MDB Files are
 > located on an W9X or LINUX Samba Share. The App closes in less then one
 > Second and is running much faster, even when an old 10MBit Network is
used.
 > Obviously the DAO ist trying to do something mysterious and time
consuming,
 > when connected to an NT like Server. We already tried to disable
 > oportunistic locking and also tried to change everything you can do inside
 > the App.
 >
 > Thanks in advance for any hints, Martin
 >
 > PS: We don't want to upgrade to a Client Server Architecture
 >
 ><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Slow Performance on WIN NT/XP/2K Shares