Access 2000 incorrectly deletes ldb file

[stu]

I have several databases that are opened using various versions of
Access and VB. Up till recently everything worked fine, then I started
getting a variety of lock file error messages, both on my PC and other
computers (both Win2k and WinXP).

After a lot of testing I found that if the database was opened by
Access 2.0 (or a VB3 16 bit application), and then subsequently a
Access 2000 (or VB6 32 bit application) opened the database, then when
the Access 2000 session ended, the LDB file was deleted, even if the
Access 2.0 session was still current. If more than 1 user was in the
database via Access 2.0 then the exit from Access 2000 corrupted the
LDB file.

The only way to clear the problem is to then get all users out of the
database and then go back in.

I don't get this problem on an older PC running Windows 98 so I suspect
that some automatic Microsoft update has caused the problem. Microsoft
told me they don't support anything to do with Access 2.0 so they
can't/won't help.

[Allen Browne]

Very interesting, Stu.

My recollection from the Access 2 days was that it did not delete the ldb on
exit, whereas Access 2000 does. I think there were some fairly major changes
to the security model after v2 as well.

I would have expected v.2 to have the file locked so it could not be deleted
though.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"stu" <st*@superdata.com.au> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

I have several databases that are opened using various versions of
Access and VB. Up till recently everything worked fine, then I started
getting a variety of lock file error messages, both on my PC and other
computers (both Win2k and WinXP).

After a lot of testing I found that if the database was opened by
Access 2.0 (or a VB3 16 bit application), and then subsequently a
Access 2000 (or VB6 32 bit application) opened the database, then when
the Access 2000 session ended, the LDB file was deleted, even if the
Access 2.0 session was still current. If more than 1 user was in the
database via Access 2.0 then the exit from Access 2000 corrupted the
LDB file.

The only way to clear the problem is to then get all users out of the
database and then go back in.

I don't get this problem on an older PC running Windows 98 so I suspect
that some automatic Microsoft update has caused the problem. Microsoft
told me they don't support anything to do with Access 2.0 so they
can't/won't help.

['69 Camaro]

Hi, Stu.

Today is your lucky day. Hardly anyone uses Access 2.0 anymore so the
problem you are encountering is very uncommon. However, someone else had
the same problem recently and actually took the time to post his solution.
Hardly anyone does that, either. And I hardly ever stop by this forum.
Please see the following Web page for a solution to your problem:

http://groups.google.co.uk/groups?hl...15abad6&rnum=1

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
"stu" <st*@superdata.com.au> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

I have several databases that are opened using various versions of
Access and VB. Up till recently everything worked fine, then I started
getting a variety of lock file error messages, both on my PC and other
computers (both Win2k and WinXP).

After a lot of testing I found that if the database was opened by
Access 2.0 (or a VB3 16 bit application), and then subsequently a
Access 2000 (or VB6 32 bit application) opened the database, then when
the Access 2000 session ended, the LDB file was deleted, even if the
Access 2.0 session was still current. If more than 1 user was in the
database via Access 2.0 then the exit from Access 2000 corrupted the
LDB file.

The only way to clear the problem is to then get all users out of the
database and then go back in.

I don't get this problem on an older PC running Windows 98 so I suspect
that some automatic Microsoft update has caused the problem. Microsoft
told me they don't support anything to do with Access 2.0 so they
can't/won't help.

[Tony Toews]

"Allen Browne" <Al*********@SeeSig.Invalid> wrote:

My recollection from the Access 2 days was that it did not delete the ldb on
exit, whereas Access 2000 does.

A2.0 did not. A97 did. Don't recall about A95 as I hardly ever used it.

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

[Dimitri Furman]

On Jan 21 2005, 12:44 am, "stu" <st*@superdata.com.au> wrote in
news:11*********************@f14g2000cwb.googlegro ups.com:

After a lot of testing I found that if the database was opened by
Access 2.0 (or a VB3 16 bit application), and then subsequently a
Access 2000 (or VB6 32 bit application) opened the database, then when
the Access 2000 session ended, the LDB file was deleted, even if the
Access 2.0 session was still current.

One possible solution is to revoke the Delete permissions on the directory
of the MDB from all users of the app. This way the LDB file stays there
forever. Basically, the same approach as pointed out in '69 Camaro's
message, only you don't need a separate app to hold the LDB file open.

--
remove a 9 to reply by email

[David W. Fenton]

Dimitri Furman <df*****@cloud99.net> wrote in
news:Xn****************************@127.0.0.1:

On Jan 21 2005, 12:44 am, "stu" <st*@superdata.com.au> wrote in
news:11*********************@f14g2000cwb.googlegro ups.com:

After a lot of testing I found that if the database was opened by
Access 2.0 (or a VB3 16 bit application), and then subsequently a
Access 2000 (or VB6 32 bit application) opened the database, then
when the Access 2000 session ended, the LDB file was deleted,
even if the Access 2.0 session was still current.

One possible solution is to revoke the Delete permissions on the
directory of the MDB from all users of the app. This way the LDB
file stays there forever. Basically, the same approach as pointed
out in '69 Camaro's message, only you don't need a separate app to
hold the LDB file open.

But then you'll have more instances of "corruption" because you'll
never be re-initializing the LDB file.

I worked in that setup for one app of mine, and I found that the
best way was to have a couple of regular users who were
administrators so that I could give delete permission to the admins
and not to the users. This meant that every now and then, the LDB
would, in fact, get deleted.

Before I made that change, we were frequently needing to delete it
by hand because the LDB was getting corrupted entries in it that
were preventing compacting.

Of course, that was all A97.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[stu]

I had already created a small VB6 app that holds the database open
which solves the problem of deletion or corruption of the LDB file, but
still doesn't address the question of why this problem arose when the
Access 2 and Access 2000 databases had been working successfully
together for the last 2 years.

[Dimitri Furman]

On Jan 22 2005, 07:51 pm, "David W. Fenton" <dX********@bway.net.invalid>
wrote in news:Xn**********************************@24.168.1 28.86:

Dimitri Furman <df*****@cloud99.net> wrote in
news:Xn****************************@127.0.0.1:

One possible solution is to revoke the Delete permissions on the
directory of the MDB from all users of the app. This way the LDB
file stays there forever. Basically, the same approach as pointed
out in '69 Camaro's message, only you don't need a separate app to
hold the LDB file open.

But then you'll have more instances of "corruption" because you'll
never be re-initializing the LDB file.

I worked in that setup for one app of mine, and I found that the
best way was to have a couple of regular users who were
administrators so that I could give delete permission to the admins
and not to the users. This meant that every now and then, the LDB
would, in fact, get deleted.

Before I made that change, we were frequently needing to delete it
by hand because the LDB was getting corrupted entries in it that
were preventing compacting.

Of course, that was all A97.

Well, I guess it depends. I had several A97 apps set up this way with zero
issues related to LDB file corruption, for about four years. That was on a
Netware network though.

--
remove a 9 to reply by email

[David W. Fenton]

"stu" <st*@superdata.com.au> wrote in
news:11**********************@z14g2000cwz.googlegr oups.com:

I had already created a small VB6 app that holds the database open
which solves the problem of deletion or corruption of the LDB
file, but still doesn't address the question of why this problem
arose when the Access 2 and Access 2000 databases had been working
successfully together for the last 2 years.

Is the server OS the same?

Has a server service pack been applied?

You'd be surprised what kinds of issues can be caused by server-side
hotfixes. I learned years ago that patches to the server OS can have
really weird side effects that have an impact on Access. In the case
where I learned this, we'd applied an Exchange hotfix (the one that
closes the message store to allow the OS to shutdown clean) and
within an hour or so, the client's replicated database "corrupted"
and in recovery, lost replicability. Eventually we identified the
proximate cause as the hotfix and backed it out, and, voila, no more
corruption/loss of replicability.

Jet interacts with the file system in some very mysterious ways, and
changes to the way the file system (including networking subsystems)
work can make Jet behave differently.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[stu]

I am guessing that it must be some sort of security problem as it
doesn't happen on a Windows 98 system. However I get the problem on
both a W2K server as well as a workstation.

I have changed the Security on the LDB file by removing Full Control
and Modify permissions and this prevents Access 2000 deleting (or
corrupting) the lock file.

This still doesn't answer the question as to why Access 2000 clobbers
the lock file on exit.

If you want to emulate the problem, open a database with Access 2.0,
then open the same database with Access 2000. Exit Access 2000 and the
LDB file is gone !.

Alternatively open several instances of a database with Access 2.0.
Then open the same database with Access 2000. Exit Access 2000 and try
and open another instance of the database with Access 2.0 - file lock
problems because the lock file is now corrupted !.

If you exit all instances of Access 2, then the LDB file disappears and
you can now re-open the database.

[David W. Fenton]

"stu" <st*@superdata.com.au> wrote in
news:11*********************@z14g2000cwz.googlegro ups.com:

If you want to emulate the problem, open a database with Access
2.0, then open the same database with Access 2000. Exit Access
2000 and the LDB file is gone !

Hmm. I don't think I'd ever contemplate a production environment
where I'd have any database opened with both Access 2 and Access 2K
(or even A97).

Is this a real scenario? Do you *really* have some people running
the application in Access 2 and some running the very same Access 2
application in Access 2K? Or do you have an Access 2 front end and
an Access 2K front end connecting to an Access 2 back end?

I don't think that's a particularly viable setup and I would upgrade
everyone to Access 2K and then upgrade the back end to Access 2K.

Previously, I had missed the point of your post, that you were
running a mixture of A2K and Access 2. That strikes me as a
remarkably iffy setup.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[david epsom dot com dot au]

I knew that Jet 4.0 can't be used simultaneously with Jet 2.5,
but repeating that wouldn't have helped you any. What is new
and interesting is that it doesn't happen on your Win 98 system,
and that you managed to work for 2 years without experiencing
this problem.

Jet 2.5 is a Win16 program, works in the Win16 emulation system
on Win2K, and uses the (emulated) Win16 file (database) API.
Your observation that this worked correctly on Win98 suggests
that there is a problem with the Win16 API emulation on Win2K,
rather than a problem with Jet 4.0 as such.

However, there have been no reported problems using Jet 3.1
simultaneously with Jet 2.5, so I guess there is a perverse
interaction between the 4 components of the database engine:
Jet 4, Jet 2.5, Win16 emulation and WinNT
(david)

"stu" <st*@superdata.com.au> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

I am guessing that it must be some sort of security problem as it
doesn't happen on a Windows 98 system. However I get the problem on
both a W2K server as well as a workstation.

I have changed the Security on the LDB file by removing Full Control
and Modify permissions and this prevents Access 2000 deleting (or
corrupting) the lock file.

This still doesn't answer the question as to why Access 2000 clobbers
the lock file on exit.

If you want to emulate the problem, open a database with Access 2.0,
then open the same database with Access 2000. Exit Access 2000 and the
LDB file is gone !.

Alternatively open several instances of a database with Access 2.0.
Then open the same database with Access 2000. Exit Access 2000 and try
and open another instance of the database with Access 2.0 - file lock
problems because the lock file is now corrupted !.

If you exit all instances of Access 2, then the LDB file disappears and
you can now re-open the database.