We've been getting this message in our back-end since January, with
all users in the database, and have yet to find a cause. It happened
every day the first week, then randomly. Usually in the middle of the
day, but at least once it happened overnight when no one was using it
(maybe twice, I can't remember for sure). We've checked for improper
shut downs and unauthorized users, found nothing. The message only
happens when someone is connecting to the back-end - opening the
front-end or a merge document. For users who already had it open it
appears to be working fine, but sometimes it slows down to a crawl.
To fix it I close and re-open the back-end, which gives a message on
opening that it needs to be repaired, would I like it repaired? I say
yes, it repairs, and after that it's fine until the next time we get
the error.
Unless...sometimes the .ldb file hangs up and won't disengage. Then
it won't repair because it thinks it still has users (usually me, and
I know I closed my front-end), and I have to call our server people
and have someone delete it off the server.
I and 2 tech support people are working on this. Monday I made a new
DB file and transferred all the objects into it, but Tuesday we got
the error again. Our DB tech sent me this info from other groups:
-----------------------------------------------------
I also found this in the same Forum. all this is available if you go
to
www.dbforums.com
I just had a nightmare with an Acces/VB system and I thought it might
save
somebody else the same trouble if I post some of the stuff I found out
while
fixing it.
The system is an Access 2000 MDB file on the server and a VB6
application that runs
on client PCs and connects via ADO 2.6. It is mission-critical for the
company I
wrote it for. The other day, the first person in to work booted his PC
and it 'went
all weird and then seemed to sort itself out'. (That's all I could get
out of him -
these people are not exactly hackers.) He then started my application
and started
using it. Soon afterwards several other clients were started too. Then
the client was
closed on the dodgy machine and, from that point on, only the clients
already
connected would work. Any other clients attempting to start would fail
at the
Connection.Open stage with the 'Unrecognized database format' error
message.
I then spent several hours screwing around re-booting clents and the
server,
uninstalling and reinstalling the app, installing Jet, reinstalling
MDAC on its own,
opening and testing connections and God knows what else. No joy at
all. I finally
decided that the database must have become corrupt. I took a deep
breath, closed the
last working clients and found there was still an LDB file. I deleted
that and tried
a new connection. Same error and (and this was interesting) the LDB
file stayed again
even though the attempt to connect failed. I opened the MDB file in
Access. It said
the database needed to be repaired. I said OK and it fixed it.
My theory is that there is some kind of header information in an MDB
file that states
what version it is and so on. This got corrupted when the dodgy
machine disconnected
so that, although clients that were alredy connected were fine, new
connections
failed because the header did not match ADO/Jet's expectations. Of
course, I'm
guessing because this is the sort of information companies like
Microsoft believe is
best kept secret. We don't need to know how it works, do we?
---------------------------------------
And this:
here is something that relates i think. the person could not get rid
of the ldb.
I, too, had a similar problem. I found that I could keep the
permissions set to
Change, but had to ensure that the directory in which the db resides
was set to not
inherit permissions from it's parent. It seemed that everytime a new
user logged onto
a given machine, it got messed up.
here is another:
I had a similar problem and it was related to directory and file
security properties;
it wasn't a 'machine' problem, but 'user' specific problem. I had to
change the
directory and file security to "All" for all database users.
and last, some guidelines for corruption.
Generally speaking ... (although this may not be news to you).
The top 5 key pointers on how to prevent corruption in the future:
(1) Ensure the front end forms are split from the backend tables -
i.e. in a
multiuser situation never have users sharing one file placed on the
network which
contains the forms and tables.
(2) Never compact and repair the database over the network, always do
this locally.
(3) If the database has been placed on a Windows 2000 Server, disable
opportunistic
locking. This is a technical issue, so please visit
http://www.datarevive.com/support/kb/kb2203.htm for further
information.
(4) Check or replace the network cards of suspect computers (faulty
network cards are
a common cause of corruption).
(5) Apply the latest service packs/software updates to Microsoft
Access.
Also,
www.access-emergency.com (a competitor of ours) has some
excellent articles
regarding sniffing for network problems as the cause of corruption, so
this is worth
checking out.
------------------------------
Tony Toews <tt****@telusplanet.net> wrote in message news:<96********************************@4ax.com>. ..
"L Mehl" <me*********@cyvest.com> wrote:
I tested a FE/BE application developed in A2000 on a A2002 machine and got
this message when exiting the app. Clicking the only available button "OK",
exits the application, as intended.
The FE is just the mdb, not an mde. FE and BE are in different directories
on the same machine.
Are there settings, preferably via code, that I can add to stop this error?
No. This is an unusual situation.
FEs usually get corrupted when you share the FE among multiple users. Yet that
doesn't sound like the situation when you stated "you tested ..." Or when opened by
another program such as Word which, once the autosave hits, unretrievably scrambles
the file.
You also shouldn't have gotten the message when exiting the MDB. Unless you are
doing some very unusual code on exiting such as, possibly, setting an opendatabase to
the FE MDB
To explain this a bit. Access momentarily sets a flag when doing updates. Access
does not check this flag when the user is in the MDB. You should only see this
message when you are opening up the MDB. So it's rather interesting that this
happened when you closed the MDB.
Tony
