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" <dXXXfenton@bway.net.invalid> wrote in message
news:Xns96CBA12282AA7dfentonbwaynetinvali@216.196. 97.142...[color=blue]
> "Bob Darlington" <bob@dpcmanAX.com.au> wrote in
> news:43201509$0$22808$afc38c87@news.optusnet.com.a u:
>[color=green]
>> 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).[/color]
>
> 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).
>[color=green]
>> I delete the ldb only if it is there (if Dir() etc).[/color]
>
> 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.
>[color=green]
>> 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.[/color]
>
> 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.
>[color=green]
>> 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.[/color]
>
> 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.
>[color=green]
>> 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.[/color]
>
> 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[/color]
