Re: Problem deleting ldb file
- From: "Nick Coe \(UK\)" <classicnickNOSPAMAT@xxxxxxxxxxxxxxxxxx>
- Date: Thu, 8 Sep 2005 18:08:37 +0100
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:43201509$0$22808$afc38c87@xxxxxxxxxxxxxxxxxxxx,
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" <keith.wilby@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> message
> news:43200426$1_1@xxxxxxxxxxxxxxxxxxxxxxxxx
>> "Bob Darlington" <bob@xxxxxxxxxxxxxxx> wrote in message
>> news:431ff5ae$0$23738$afc38c87@xxxxxxxxxxxxxxxxxxxxxxx
>>> 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
.
- References:
- Problem deleting ldb file
- From: Bob Darlington
- Re: Problem deleting ldb file
- From: Keith
- Re: Problem deleting ldb file
- From: Bob Darlington
- Problem deleting ldb file
- Prev by Date: Re: How to parse CITY ST ZIP+/-4
- Next by Date: "Too many Fields" error running query with <255 fields
- Previous by thread: Re: Problem deleting ldb file
- Next by thread: Re: Problem deleting ldb file
- Index(es):
Relevant Pages
|
