persistent ldb file balking scheduled vbscript

[Mic]

Hi,

I am having trouble with an ldb file which I cannot delete. The
database is the backend of a web application; a cleanup vbscript for
it runs as a scheduled task daily. It was all working fine until all
of a sudden (Wednesday 6/23), the script failed. It looks like the
existence of the ldb file probably stopped it, though it's possible
that it was the script itself running the day before which created the
file in the first place.

When I've encountered this previously, restarting IIS has always been
enough to get rid of the ldb. (Manually deleting it appears to work,
but as soon as I refresh the folder, the ldb just comes right back.)
Unfortunately now, even when I restart IIS, the ldb remains. Thus I
can't even test the script to debug it...

Has anybody encountered this before? How do I get rid of a persistent
ldb file when restarting IIS fails?

Also, I did already check out the ldb via MS's LDB Viewer utility. It
shows three users (all three the server itself), one as logged on and
not suspect, and two as not logged on and suspect. No committed
transactions. Interestingly, if I access the database through my
computer, its name then replaces the middle of the three users (always
the middle!) and won't disappear (even if I exit properly) until I
logoff my computer or restart IIS. When I'm in it says logged on and
not suspect; when I exit, logged off and suspect.

Bizarrely, through the web I can successfully access the same tables
that are presumably causing the locking issues with the script. (I'm
guessing that these are the ones I can't Design View without getting a
locking error.)

Michelle

 

[Tony Toews]

I am having trouble with an ldb file which I cannot delete. The
database is the backend of a web application; a cleanup vbscript for
it runs as a scheduled task daily. It was all working fine until all
of a sudden (Wednesday 6/23), the script failed. It looks like the
existence of the ldb file probably stopped it, though it's possible
that it was the script itself running the day before which created the
file in the first place.

When I've encountered this previously, restarting IIS has always been
enough to get rid of the ldb. (Manually deleting it appears to work,
but as soon as I refresh the folder, the ldb just comes right back.)
Unfortunately now, even when I restart IIS, the ldb remains. Thus I
can't even test the script to debug it...

Has anybody encountered this before? How do I get rid of a persistent
ldb file when restarting IIS fails?

To me IIS is doing something weird here because how else is it
recreating the LDB file? You should be able to look through the
server file locks to see exactly what process, etc has the mdb/ldb
open? Just to confirm that it is indeed IIS.

Also, I did already check out the ldb via MS's LDB Viewer utility. It
shows three users (all three the server itself), one as logged on and
not suspect, and two as not logged on and suspect. No committed
transactions. Interestingly, if I access the database through my
computer, its name then replaces the middle of the three users (always
the middle!) and won't disappear (even if I exit properly) until I
logoff my computer or restart IIS. When I'm in it says logged on and
not suspect; when I exit, logged off and suspect.

The suspect status in Jet 4.0 is misleading when using LDB View. See
http://www.granite.ab.ca/access/corruption/workstation.htm for more
details. And see "Note This utility was not tested with Jet 4.0
databases" at http://support.microsoft.com/?kbid=176670.

The behaviour of the middle entry being replaced with yours is
consistent with IIS, or something else on the server computer, using
the first entry. If you were to open Access against that MDB a
second time you should see the third entry being taken up. Or if you
were to go to another system.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[david epsom dot com dot au]

You can't delete a file while it is in use: Windows can loose
track if the user/application does not notify windows that the
file is no longer in use: This may happen if the user/application
crashes or fails: Windows will normally time-out connections
if a user is disconnected: Just turning off IIS and restarting
it would not give Windows long enough to time out a broken
connection: An Administrator should be able to delete a file
that is in use: Just deleting the LDB is probably not enough,
because there are probably file locks on the MDB as well: Since
IIS is running with a local login rather than a network login,
it may be more difficult to break the connection between the
IIS 'user' and the file: It's little things like this that
make MDB files difficult to use in a Web application

(david)