By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,869 Members | 1,756 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,869 IT Pros & Developers. It's quick & easy.

Problem deleting ldb file

P: n/a
I have a repair and backup database routine which runs when a user closes
down my application.
It works fine in my development machine, but breaks on a client's at the
following line:
If Dir(strLDB) <> "" Then Kill (strLDB)
where strLDB is the path to the ldb file.
The client advises that the ldb doesn't lurk after the program closes.
Any ideas?
--
Bob Darlington
Brisbane
Nov 13 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in message
news:43***********************@news.optusnet.com.a u...
I have a repair and backup database routine which runs when a user closes
down my application.
It works fine in my development machine, but breaks on a client's at the
following line:
If Dir(strLDB) <> "" Then Kill (strLDB)
where strLDB is the path to the ldb file.
The client advises that the ldb doesn't lurk after the program closes.

Does this code run from the app that is closing? If so then I'm confused as
to why you're trying to kill a file that is about to delete itself anyway.
If not, it is normal behaviour for the ldb to be deleted when the mdb closes
so I would have expected strLDB to be zero-length at all times. Is this not
what you are finding? "the ldb doesn't lurk after the program closes"
suggests that it is deleted so why your code should fail at that line is a
mystery to me ... perhaps another error is being masked somehow?

BTW it's not recommended to attempt to repair a database that doesn't
specifically need repairing.

Regards,
Keith.
www.keithwilby.com
Nov 13 '05 #2

P: n/a
Keith,
Thanks for the reply.
I forgot the mention that:
1. The error when the code breaks is Err 70 - Permission denied.
2. The database is split, and I'm trying to compact/repair the backend
3. The client has full permissions on the folder holding the data file.

The code runs before the app closes (otherwise I couldn't run it from within
the code).
I delete the ldb only if it is there (if Dir() etc).
So that if the line fails, then I presume that it is still there and the
code is trying to Kill it.
My question is why does it fail on the client machine but not on mine.

The reason for repairing and compacting (same operation) before backing up
is to ensure that the backup isn't saving a corrupted file - something which
occurred at one of my sites some years back, and to compact the data file to
conserve disk space.
I've never really understood why 'it's not recommended to attempt to repair
a database that doesn't
specifically need repairing'. Especially since you can't compact without
repairing.
But perhaps someone will enlighten me.

--
Bob Darlington
Brisbane
"Keith" <ke*********@baeAWAYWITHITsystems.com> wrote in message
news:43**********@glkas0286.greenlnk.net...
"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in message
news:43***********************@news.optusnet.com.a u...
I have a repair and backup database routine which runs when a user closes
down my application.
It works fine in my development machine, but breaks on a client's at the
following line:
If Dir(strLDB) <> "" Then Kill (strLDB)
where strLDB is the path to the ldb file.
The client advises that the ldb doesn't lurk after the program closes.

Does this code run from the app that is closing? If so then I'm confused
as to why you're trying to kill a file that is about to delete itself
anyway. If not, it is normal behaviour for the ldb to be deleted when the
mdb closes so I would have expected strLDB to be zero-length at all times.
Is this not what you are finding? "the ldb doesn't lurk after the program
closes" suggests that it is deleted so why your code should fail at that
line is a mystery to me ... perhaps another error is being masked somehow?

BTW it's not recommended to attempt to repair a database that doesn't
specifically need repairing.

Regards,
Keith.
www.keithwilby.com

Nov 13 '05 #3

P: n/a
"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in message
news:43***********************@news.optusnet.com.a u...

[snip]
I've never really understood why 'it's not recommended to attempt to repair a
database that doesn't
specifically need repairing'. Especially since you can't compact without
repairing.
But perhaps someone will enlighten me.


Actually when you perform Compact/Repair you are only guaranteed that Compact
will occur. Access itself decides whether the Repair is required and only
executes it when it is. On older versions where Compact and Repair are separate
menu items it is possible to do a Repair on a file that doesn't need it. On
newer versions it is not.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #4

P: n/a
hi Bob, comments in-line ...

"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in message
news:43***********************@news.optusnet.com.a u...
Keith,
Thanks for the reply.
I forgot the mention that:
1. The error when the code breaks is Err 70 - Permission denied.
2. The database is split, and I'm trying to compact/repair the backend
3. The client has full permissions on the folder holding the data file.

The code runs before the app closes (otherwise I couldn't run it from
within the code).
I delete the ldb only if it is there (if Dir() etc).
This is the bit I don't get - if the app is still open then it will still
need its ldb.
So that if the line fails, then I presume that it is still there and the
code is trying to Kill it.
My question is why does it fail on the client machine but not on mine.
I would have expected it to fail regardless of machine, unless I'm missing
something about precisely when an mdb releases the ldb.
<snip> I've never really understood why 'it's not recommended to attempt to
repair a database that doesn't
specifically need repairing'. Especially since you can't compact without
repairing.
But perhaps someone will enlighten me.

It depends on the version you're using but in A97 you can compact without
repairing. My comment was made wearing my A97 hat. AIUI in later versions,
"repair" will only happen if Access detects a defect that requires
repairing.

Regards,
Keith.
Nov 13 '05 #5

P: n/a
The fact that an ldb file exists means that either
Access/Jet has the mdb open or that the mdb has not been
closed properly and is now in an indeterminate state. This
applies to a data mdb as much as an app mdb.

Close the app on the clients machine and Access, then use
Windows Explorer to examine the folder where the ldb
normally resides. Is it still there? With Versions of
Access from 97 on the ldb will be deleted without you having
to do anything unless somethings gone wrong or another user
has the mdb open.

I wouldn't try to delete the ldb for the back end in code,
there's really nothing to be gained. Let it happen
automagically.

--
Nick Coe (UK)
Available - Will work for money :-)
http://www.alphacos.co.uk/ AccHelp + pAnimal
http://www.pjandcoe.co.uk/ Online Store

In news:43***********************@news.optusnet.com.a u,
Bob Darlington typed:
Keith,
Thanks for the reply.
I forgot the mention that:
1. The error when the code breaks is Err 70 - Permission
denied. 2. The database is split, and I'm trying to
compact/repair the
backend 3. The client has full permissions on the folder
holding the
data file.
The code runs before the app closes (otherwise I couldn't
run
it from within the code).
I delete the ldb only if it is there (if Dir() etc).
So that if the line fails, then I presume that it is still
there and the code is trying to Kill it.
My question is why does it fail on the client machine but
not
on mine.
The reason for repairing and compacting (same operation)
before backing up is to ensure that the backup isn't
saving a
corrupted file - something which occurred at one of my
sites
some years back, and to compact the data file to conserve
disk
space. I've never really understood why 'it's not
recommended to
attempt to repair a database that doesn't
specifically need repairing'. Especially since you can't
compact without repairing.
But perhaps someone will enlighten me.
"Keith" <ke*********@baeAWAYWITHITsystems.com> wrote in
message
news:43**********@glkas0286.greenlnk.net...
"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in message
news:43***********************@news.optusnet.com.a u...
I have a repair and backup database routine which runs
when
a user closes down my application.
It works fine in my development machine, but breaks on a
client's at the following line:
If Dir(strLDB) <> "" Then Kill (strLDB)
where strLDB is the path to the ldb file.
The client advises that the ldb doesn't lurk after the
program closes.

Does this code run from the app that is closing? If so
then
I'm confused as to why you're trying to kill a file that
is
about to delete itself anyway. If not, it is normal
behaviour
for the ldb to be deleted when the mdb closes so I would
have
expected strLDB to be zero-length at all times. Is this
not
what you are finding? "the ldb doesn't lurk after the
program closes" suggests that it is deleted so why your
code
should fail at that line is a mystery to me ... perhaps
another error is being masked somehow? BTW it's not
recommended to attempt to repair a database that
doesn't specifically need repairing.

Regards,
Keith.
www.keithwilby.com

Nov 13 '05 #6

P: n/a
"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in
news:43***********************@news.optusnet.com.a u:
Keith,
Thanks for the reply.
I forgot the mention that:
1. The error when the code breaks is Err 70 - Permission denied.
2. The database is split, and I'm trying to compact/repair the
backend
3. The client has full permissions on the folder holding
the data file.

The code runs before the app closes (otherwise I couldn't run it
from within the code).
AN LDB file can't be deleted as long as there are any open
connections to the MDB the LDB is for. That means that if there are
multiple users, no single user will be able to delete the LDB when
other users are in the database.

Of ocurse, if there *aren't* any other users, and the LDB is in a
file where users have delete permission, then the LDB will
automatically be delted when the last user exits. This has been the
case since the introduction of Access95. It was only in Access 2
that you had left-over LDB files (not that it often mattered).
I delete the ldb only if it is there (if Dir() etc).
Well, are all the forms in your front end closed? Are all recordsets
and database variables set to Nothing? If not, the LDB will still be
there, and you won't be able to delete it.

If you *have* done all those things and you're the last user, you're
deleting something that is going to be deleted anyway.
So that if the line fails, then I presume that it is still there
and the code is trying to Kill it.
My question is why does it fail on the client machine but not on
mine.
1. multiple users -- someone else is still using the back end

2. connections from the user's database still open

3. no delete permission on the folder where the LDB was created.
The reason for repairing and compacting (same operation) before
backing up is to ensure that the backup isn't saving a corrupted
file - something which occurred at one of my sites some years
back, and to compact the data file to conserve disk space.
Sometimes a corrupted MDB will lose data during a compact, data that
is still accessible *before* the compact. So, you should relaly be
saving both versions, the one before the compact and the one after,
because you may need the one before the compact. A typical example
of where data can be lost is if there's a corrupted index. A compact
will often drop the index and sometimes records are lost in the
process. Those records may or may not be accessible before the
compact that attempted to fix the corrupted index.
I've never really understood why 'it's not recommended to attempt
to repair a database that doesn't
specifically need repairing'. Especially since you can't compact
without repairing.
But perhaps someone will enlighten me.


In all versions of Access after SR1 of A97, any compact does a
repair *if* there's something needing repairing. In A2K, the REPAIR
command was removed as a separate step. The reason was because it
was made a part of the compact process that ran only if there was
something damaged that needed to be repaired. The reason for this
change was that a repair that was run from the menu item when there
was nothing damaged could in some rare circumstances cause damage.

In other words, unnecessary repairs could damage your data.

So, Microsoft removed it as a choice for the end user.

Now, I don't know why you're deleting the LDB file. If the database
is not in use by someone else, the LDB file will be deleted, anyway,
so it won't get in the way of your compact operation. If Jet can't
automatically delete the LDB at the point that the last user
disconnects, then there's a problem that's outside of Jet and you
won't be able to delete it from Access, either.

So, basically, your code to delete the LDB is a waste of time. Just
don't bother, and you won't have any more problems.

Where problems *do* arise, your code wouldn't have worked, anyway.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #7

P: n/a
Thanks for your comprehensive reply.
I've had this line of code in my apps for so long that I can't remember the
logic which led to it in the first place.
It isn't run until all users are out of the program.
Anyway, I'll take it out for now.

But as an aside, you (and others) have mentioned that the ldb is closed when
the program closes anyway, but I've found this not to always to be the case
at one site where 12 users are using TS over a mixture of broadband and LAN
on Windows 2000 Server. Occasionally, the ldb doesn't go away and I need to
go in and remove MSAccess.exe from Task Manager Processes before I can
delete it. I presume that this results from the application being shut down
by connection failures (but not sure).
(I know that my code won't work in that situation)

I take your point regarding the risk of compacting a corrupted file, and I
do make a copy before doing so.
I've always thought that if a corruption had occurred an error would be
generated by the Compact/Repair, (if the problem was not repaired).
Therefore, I wouldn't be happily saving a corrupted backup without knowing
it. From what you say, I'm wrong here, but is there a recommended test for
corruption which I can run instead of the compact routine?
Bob Darlington
Brisbane
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142...
"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in
news:43***********************@news.optusnet.com.a u:
Keith,
Thanks for the reply.
I forgot the mention that:
1. The error when the code breaks is Err 70 - Permission denied.
2. The database is split, and I'm trying to compact/repair the
backend
3. The client has full permissions on the folder holding
the data file.

The code runs before the app closes (otherwise I couldn't run it
from within the code).


AN LDB file can't be deleted as long as there are any open
connections to the MDB the LDB is for. That means that if there are
multiple users, no single user will be able to delete the LDB when
other users are in the database.

Of ocurse, if there *aren't* any other users, and the LDB is in a
file where users have delete permission, then the LDB will
automatically be delted when the last user exits. This has been the
case since the introduction of Access95. It was only in Access 2
that you had left-over LDB files (not that it often mattered).
I delete the ldb only if it is there (if Dir() etc).


Well, are all the forms in your front end closed? Are all recordsets
and database variables set to Nothing? If not, the LDB will still be
there, and you won't be able to delete it.

If you *have* done all those things and you're the last user, you're
deleting something that is going to be deleted anyway.
So that if the line fails, then I presume that it is still there
and the code is trying to Kill it.
My question is why does it fail on the client machine but not on
mine.


1. multiple users -- someone else is still using the back end

2. connections from the user's database still open

3. no delete permission on the folder where the LDB was created.
The reason for repairing and compacting (same operation) before
backing up is to ensure that the backup isn't saving a corrupted
file - something which occurred at one of my sites some years
back, and to compact the data file to conserve disk space.


Sometimes a corrupted MDB will lose data during a compact, data that
is still accessible *before* the compact. So, you should relaly be
saving both versions, the one before the compact and the one after,
because you may need the one before the compact. A typical example
of where data can be lost is if there's a corrupted index. A compact
will often drop the index and sometimes records are lost in the
process. Those records may or may not be accessible before the
compact that attempted to fix the corrupted index.
I've never really understood why 'it's not recommended to attempt
to repair a database that doesn't
specifically need repairing'. Especially since you can't compact
without repairing.
But perhaps someone will enlighten me.


In all versions of Access after SR1 of A97, any compact does a
repair *if* there's something needing repairing. In A2K, the REPAIR
command was removed as a separate step. The reason was because it
was made a part of the compact process that ran only if there was
something damaged that needed to be repaired. The reason for this
change was that a repair that was run from the menu item when there
was nothing damaged could in some rare circumstances cause damage.

In other words, unnecessary repairs could damage your data.

So, Microsoft removed it as a choice for the end user.

Now, I don't know why you're deleting the LDB file. If the database
is not in use by someone else, the LDB file will be deleted, anyway,
so it won't get in the way of your compact operation. If Jet can't
automatically delete the LDB at the point that the last user
disconnects, then there's a problem that's outside of Jet and you
won't be able to delete it from Access, either.

So, basically, your code to delete the LDB is a waste of time. Just
don't bother, and you won't have any more problems.

Where problems *do* arise, your code wouldn't have worked, anyway.

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

Nov 13 '05 #8

P: n/a
Rick, Keith and Nick,
Thanks for the replies. See my response under David Fenton's post.

--
Bob Darlington
Brisbane
"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in message
news:43***********************@news.optusnet.com.a u...
Keith,
Thanks for the reply.
I forgot the mention that:
1. The error when the code breaks is Err 70 - Permission denied.
2. The database is split, and I'm trying to compact/repair the backend
3. The client has full permissions on the folder holding the data file.

The code runs before the app closes (otherwise I couldn't run it from
within the code).
I delete the ldb only if it is there (if Dir() etc).
So that if the line fails, then I presume that it is still there and the
code is trying to Kill it.
My question is why does it fail on the client machine but not on mine.

The reason for repairing and compacting (same operation) before backing up
is to ensure that the backup isn't saving a corrupted file - something
which occurred at one of my sites some years back, and to compact the data
file to conserve disk space.
I've never really understood why 'it's not recommended to attempt to
repair a database that doesn't
specifically need repairing'. Especially since you can't compact without
repairing.
But perhaps someone will enlighten me.

--
Bob Darlington
Brisbane
"Keith" <ke*********@baeAWAYWITHITsystems.com> wrote in message
news:43**********@glkas0286.greenlnk.net...
"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in message
news:43***********************@news.optusnet.com.a u...
I have a repair and backup database routine which runs when a user closes
down my application.
It works fine in my development machine, but breaks on a client's at the
following line:
If Dir(strLDB) <> "" Then Kill (strLDB)
where strLDB is the path to the ldb file.
The client advises that the ldb doesn't lurk after the program closes.

Does this code run from the app that is closing? If so then I'm confused
as to why you're trying to kill a file that is about to delete itself
anyway. If not, it is normal behaviour for the ldb to be deleted when the
mdb closes so I would have expected strLDB to be zero-length at all
times. Is this not what you are finding? "the ldb doesn't lurk after the
program closes" suggests that it is deleted so why your code should fail
at that line is a mystery to me ... perhaps another error is being masked
somehow?

BTW it's not recommended to attempt to repair a database that doesn't
specifically need repairing.

Regards,
Keith.
www.keithwilby.com


Nov 13 '05 #9

P: n/a
"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in
news:43**********************@news.optusnet.com.au :
But as an aside, you (and others) have mentioned that the ldb is
closed when the program closes anyway, but I've found this not to
always to be the case at one site where 12 users are using TS over
a mixture of broadband and LAN on Windows 2000 Server.
Occasionally, the ldb doesn't go away and I need to go in and
remove MSAccess.exe from Task Manager Processes before I can
delete it. I presume that this results from the application being
shut down by connection failures (but not sure).
(I know that my code won't work in that situation)
We;;. in those cases, the connection has not been closed. That is an
error condition and you should try to troubleshoot the environment
to figure out why it's happening.
I take your point regarding the risk of compacting a corrupted
file, and I do make a copy before doing so.
I've always thought that if a corruption had occurred an error
would be generated by the Compact/Repair, (if the problem was not
repaired). . . .
You don't necessarily get a report, no == it entirely depends on
what kind of corruption it is.
. . . Therefore, I wouldn't be happily saving a corrupted
backup without knowing it. From what you say, I'm wrong here, but
is there a recommended test for corruption which I can run instead
of the compact routine?


If you've got a regular compact routine, I'd make sure I never
overwrite versions, in order that if I've lost data due to a compact
of a corrupted file, I'll still have available all the interim
versions.

The one time I had a corrupted index (A2K, before SP6 was released)
it was precisely because we had all the backup tapes that we were
able to recover all but two of the records lost to the corrupted
index.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #10

P: n/a
Thanks again David.
I never overwrite the backups. They all go into their own date stamped
folders.
The IT contractor for the client site is looking into the connection
problem, but so far no joy, except to suggest Win 2003 Server 'might' solve
the problem.

Any ideas regarding an alternative to check for corruption? I already run a
routine to check indices on tables.

--
Bob Darlington
Brisbane
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142...
"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in
news:43**********************@news.optusnet.com.au :
But as an aside, you (and others) have mentioned that the ldb is
closed when the program closes anyway, but I've found this not to
always to be the case at one site where 12 users are using TS over
a mixture of broadband and LAN on Windows 2000 Server.
Occasionally, the ldb doesn't go away and I need to go in and
remove MSAccess.exe from Task Manager Processes before I can
delete it. I presume that this results from the application being
shut down by connection failures (but not sure).
(I know that my code won't work in that situation)


We;;. in those cases, the connection has not been closed. That is an
error condition and you should try to troubleshoot the environment
to figure out why it's happening.
I take your point regarding the risk of compacting a corrupted
file, and I do make a copy before doing so.
I've always thought that if a corruption had occurred an error
would be generated by the Compact/Repair, (if the problem was not
repaired). . . .


You don't necessarily get a report, no == it entirely depends on
what kind of corruption it is.
. . . Therefore, I wouldn't be happily saving a corrupted
backup without knowing it. From what you say, I'm wrong here, but
is there a recommended test for corruption which I can run instead
of the compact routine?


If you've got a regular compact routine, I'd make sure I never
overwrite versions, in order that if I've lost data due to a compact
of a corrupted file, I'll still have available all the interim
versions.

The one time I had a corrupted index (A2K, before SP6 was released)
it was precisely because we had all the backup tapes that we were
able to recover all but two of the records lost to the corrupted
index.

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

Nov 13 '05 #11

P: n/a
Further to my previous post, I've come across a suggestion made by Peter
Miller in one of the ng in 2002, and am
contemplating including the following code in the shutdown routine before
backup.
Any comments?
Should I have started a new thread with this???

Function CheckForCorruption() As Boolean
'---------------------------------------------------------------------------------------
' Procedure : CheckForCorruption
' DateTime : 09/09/2005 15:17
' Author : Bob Darlington
' Purpose : Check to see that backend data tables are not corrupted
'---------------------------------------------------------------------------------------
'
10 On Error GoTo CheckForCorruption_Error

Dim db As Database, rs As Recordset, td As TableDef
Dim strName As String

20 Set db = OpenDatabase(CurrentDataFile) 'BE

30 DoCmd.Hourglass True

40 For Each td In db.TableDefs
50 strName = td.Name
60 Set rs = db.OpenRecordset("Select Count(*) as vCount FROM " &
strName)
70 Set rs = Nothing
80 Next

90 CheckForCorruption = True

CloseFunction:
100 On Error Resume Next
110 DoCmd.Hourglass False
120 On Error GoTo 0
130 Exit Function

CheckForCorruption_Error:

140 MsgBox "Error: " & Err.Description & vbCrLf _
& "Error Number: " & Err.Number & vbCrLf _
& "Line Number: " & Erl & ": " & vbCrLf _
& "Possible corrupted table: " & strName
150 Resume CloseFunction

End Function
--
Bob Darlington
Brisbane
Nov 13 '05 #12

P: n/a
"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in
news:43**********************@news.optusnet.com.au :
Thanks again David.
I never overwrite the backups. They all go into their own date
stamped folders.
The IT contractor for the client site is looking into the
connection problem, but so far no joy, except to suggest Win 2003
Server 'might' solve the problem.
That's a doubtful presumption, in my opinion.
Any ideas regarding an alternative to check for corruption? I
already run a routine to check indices on tables.


I've never had enough corruption to justify trying to check for it.
The system should be stable and reliable. Untikl you've got that,
you're just wasting your time, since you can never really avoid
corruption, only detect it after it's happened. It's better to spend
your time eliminating the problems that cause the corruption than on
writing code to try to detect it.

The only exception I've ever made to that was in replicated
databases, which can very easily lose replicable status. I wrote a
check on this as an alert to the administrator of a database that
was repeatedly losing replicability without corrupting the database.
We eventually identified the cause of that problem and were able to
eliminate it entirely, so the code was useful only during the time
that we were scratching our heads trying to figure out what was
causing the problem in the first place.

I wouldn't do such a thing with a non-replicated database, as the
issues are entirely different.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #13

P: n/a
"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in
news:43**********************@news.optusnet.com.au :
Further to my previous post, I've come across a suggestion made by
Peter Miller in one of the ng in 2002, and am
contemplating including the following code in the shutdown routine
before backup.


I would never have any kind of compact-on-close operation. I just
think it's asking for trouble, as it's going to happen when it isn't
needed.

I've never needed the kind of code that you quoted and think that
you're spending time on trying to detect corruption instead of
cleaning up the operating environment so that corruption doesn't
happen in the first place.

Corruption should be a VERY RARE occurence. It certainly has been in
my Access career, stretching just shy of 10 years.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.