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

Unrecognized database format 'filename.mdb'

P: n/a
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?

Thank you for any help.

Larry Mehl
Nov 12 '05 #1
Share this Question
Share on Google+
14 Replies


P: n/a
"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
--
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
Nov 12 '05 #2

P: n/a
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

Nov 12 '05 #3

P: n/a
jb******@oldrepublic.com (Julia Baresch) wrote in
news:50**************************@posting.google.c om:
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.


You don't say which version of Access you're using, but it's very
common in A2K.

The first thing to check is that all your workstations (that's ALL
OF THEM, ONE HUNDRED PERCENT, not all but one or two) have stable
versions of Access and Jet. This means:

1. NOT the original version of Access 2K -- you need at least SR1a.

2. NOT Jet 4.0 before service pack 6 -- only SP6 and later are
usable at all.

And, to repeat, every single workstation needs to be the proper
version.

I've been through this kind of thing repeatedly with a number of
clients. These two steps ALWAYS eliminate the problem.

But it can recur (and does so) because workstations have a nasty
habit of reverting to earlier versions, because they get replaced
with new ones, Access gets re-installed, or some other application
downgrades Jet 4.

Most of my A2K apps now have a login routine that logs the user
name, workstation, date/time and the versions of MSACCESS.EXE and
MSJET40.dll. When corruption develops, I look at this table and know
exactly which machine needs to be fixed.

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

P: n/a
jb******@oldrepublic.com (Julia Baresch) wrote:
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.


You've got some solutions in the postings you've reposted and from David Fenton. I
should've also added my standard blurb on this topic.

For more information on corruption including possible causes, determining the
offending PC, retrieving your data, links, official MS KB articles and a list of
vendors who state they can fix corruption see the Microsoft Access Corruption FAQ at
http://www.granite.ab.ca/access/corruptmdbs.htm

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
Nov 12 '05 #5

P: n/a
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
Most of my A2K apps now have a login routine that logs the user
name, workstation, date/time and the versions of MSACCESS.EXE and
MSJET40.dll. When corruption develops, I look at this table and know
exactly which machine needs to be fixed.


How do you determine the Access version and Jet versions via code? Or
are you merely getting the file dates of msaccess.exe & msjet40.dll?
Also, how would you get the MDAC version?
Thanks,
Fred Zuckerman
San Diego, CA, USA
Nov 12 '05 #6

P: n/a
On 5 May 2004 19:07:10 -0700, zu********@sbcglobal.net (Fred Zuckerman) wrote:
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
Most of my A2K apps now have a login routine that logs the user
name, workstation, date/time and the versions of MSACCESS.EXE and
MSJET40.dll. When corruption develops, I look at this table and know
exactly which machine needs to be fixed.


How do you determine the Access version and Jet versions via code? Or
are you merely getting the file dates of msaccess.exe & msjet40.dll?
Also, how would you get the MDAC version?
Thanks,
Fred Zuckerman
San Diego, CA, USA


This might help.
Posted by Chuck Grimsby (15/4/2001)

You have to use a series of API calls to do this. Please note, I'm
using a slightly modified version of VS_FIXEDFILEINFO that someone
showed me which can get around using dwLowWord and dwHighWord.

Private Declare Function GetFileVersionInfo _
Lib "Version.dll" _
Alias "GetFileVersionInfoA" _
(ByVal lptstrFilename As String, _
ByVal dwhandle As Long, _
ByVal dwlen As Long, _
lpData As Any) _
As Long

Private Declare Function GetFileVersionInfoSize _
Lib "Version.dll" _
Alias "GetFileVersionInfoSizeA" _
(ByVal lptstrFilename As String, _
lpdwHandle As Long) As Long

Private Declare Function VerQueryValue _
Lib "Version.dll" _
Alias "VerQueryValueA" _
(pBlock As Any, _
ByVal lpSubBlock As String, _
lpBuffer As Any, _
puLen As Long) _
As Long

Private Declare Sub CopyMem _
Lib "kernel32" _
Alias "RtlMoveMemory" _
(Destination As Any, _
Source As Any, _
ByVal Length As Long)

Private Type VS_FIXEDFILEINFO
dwSignature As Long
dwStrucVersionl As Integer
dwStrucVersionh As Integer
dwFileVersionMSl As Integer
dwFileVersionMSh As Integer
dwFileVersionLSl As Integer
dwFileVersionLSh As Integer
dwProductVersionMSl As Integer
dwProductVersionMSh As Integer
dwProductVersionLSl As Integer
dwProductVersionLSh As Integer
dwFileFlagsMask As Long
dwFileFlags As Long
dwFileOS As Long
dwFileType As Long
dwFileSubtype As Long
dwFileDateMS As Long
dwFileDateLS As Long
End Type

Public Function GetFileVersion(strFileName As String) As String
Dim lngReturn As Long
Dim Buffer() As Byte
Dim BufferLength As Long
Dim lpBuffer As Long
Dim FileInfo As VS_FIXEDFILEINFO
Dim puLen As Long
Dim sBlock As String

BufferLength = GetFileVersionInfoSize(strFileName, _
lngReturn)
ReDim Buffer(BufferLength)

Call GetFileVersionInfo(strFileName, _
0&, _
BufferLength, _
Buffer(0))

Call VerQueryValue(Buffer(0), _
"\", _
lpBuffer, _
puLen)

Call CopyMem(FileInfo, _
ByVal lpBuffer, _
Len(FileInfo))

GetFileVersion = Format$(FileInfo.dwFileVersionMSh) & _
"." & _
Format$(FileInfo.dwFileVersionMSl, "00") & _
"."

If FileInfo.dwFileVersionLSh > 0 Then
GetFileVersion = FileVer & _
Format$(FileInfo.dwFileVersionLSh, "00") & _
Format$(FileInfo.dwFileVersionLSl, "00")
Else
GetFileVersion = FileVer & _
Format$(FileInfo.dwFileVersionLSl, "0000")
End If
End Function
Wayne Gillespie
Gosford NSW Australia
Nov 12 '05 #7

P: n/a
zu********@sbcglobal.net (Fred Zuckerman) wrote in
news:2f**************************@posting.google.c om:
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
Most of my A2K apps now have a login routine that logs the user
name, workstation, date/time and the versions of MSACCESS.EXE and
MSJET40.dll. When corruption develops, I look at this table and
know exactly which machine needs to be fixed.
How do you determine the Access version and Jet versions via code?
Or are you merely getting the file dates of msaccess.exe &
msjet40.dll?


Well, I've been thinking about packaging up my log table and the
functions I use for this into a sample app posted on my website.
Anyone interested? It would be a good way for me to avoid my
assigned tasks for the day today.

Hint, hint. ;)
Also, how would you get the MDAC version?


Why would the MDAC version matter in an Access app?

I don't use MDAC, since ADO (and everything else in MDAC) is
irrelevant to my work, so I really don't know the answer.

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

P: n/a

On Wed, 05 May 2004 04:48:13 GMT, Tony Toews <tt****@telusplanet.net>
wrote in comp.databases.ms-access:
So it's rather interesting that this happened when you closed the MDB.


'compact on close' = true

Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
Nov 12 '05 #9

P: n/a
Peter Miller <pm*****@pksolutions.com> wrote:
So it's rather interesting that this happened when you closed the MDB.


'compact on close' = true


Ah, interesting. I don't recall seeing this anywhere before. Any idea on the how
this causes corruptions?

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
Nov 12 '05 #10

P: n/a
Peter Miller <pm*****@pksolutions.com> wrote:
So it's rather interesting that this happened when you closed the MDB.


'compact on close' = true


And I never do this as I'm running multi user FE/BEs so this never even occurred to
me. <sigh>

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
Nov 12 '05 #11

P: n/a

Tony,

On Fri, 07 May 2004 22:30:37 GMT, Tony Toews <tt****@telusplanet.net>
wrote in comp.databases.ms-access:
Ah, interesting. I don't recall seeing this anywhere before. Any idea on the how
this causes corruptions?


As you probably know, security information tends to reside towards the
end of a database file (even though the msysaces table has a low table
id, and its definition is stored early in the file). For a file that
has a lot of data, and only recently had permissions changes made,
this might be expected, but even for well-organized files with no
permission changes since initial development, we see it being more
likely than not that permission information resides towards the rear
of the file.

What does this have to do with corruption?

Some types of corruption cause Access to fail when it attempts to
compact/repair. We see some cases where the user believes their file
is intact, when in fact, it clearly was corrupted at a certain point,
and the compact/repair failed. Specifically, we see cases where the
user's tables and data appear fine, but the MSysAces security
permissions table is missing all records. It appears Access fails to
write this tables contents out, after corruption is encountered, and
as such, the user gets permission denied messages, even on a file that
never had security added in the first place.

Of course, the reason for this is that all Access databases are always
secured from the outset, in the sense that the admin user has, by
default, rights (ie, permission records) to all objects. So if
records are skipped for the MSysAces table, the database will appear
locked even when no security was enforced by the user. This appears
to be linked to compacting in many cases.

In any event, while it is VERY GOOD PRACTICE (all caps for general
readers - not you, Tony) to frequently compact database files,
especially after changes to table structures, or mass
updates/deletes/inserts, it is very bad practice (imnsho) to se4t the
compact on close flag to true. Why? Because compacting after *every*
use is overkill, and more to the point, compact can fail. Usually
this leaves you with a corrupted but not compacted original file, and
an errant, partially created, db1.mdb (or dbN.mdb) file which
represents the partial output from the compact process, but sometimes
it can result in the compacted file appearing to Access to be fine
(ie, and so the original file is deleted) when in fact it has been
truncated and further corrupted by the compact process. A better
solution is either to manually or automatically (through your own code
- not setting compact-on-close to true) do the compact periodically
such that a backup of the pre-compacted file is made and retained
until it is confirmed that the results of the compact process are
useful and complete.

HTH,
Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
Nov 12 '05 #12

P: n/a
Peter Miller <pm*****@pksolutions.com> wrote:

As you probably know, security information tends to reside towards the
end of a database file (even though the msysaces table has a low table
id, and its definition is stored early in the file).
No, I didn't know that.
In any event, while it is VERY GOOD PRACTICE (all caps for general
readers - not you, Tony) to frequently compact database files,
especially after changes to table structures, or mass
updates/deletes/inserts,
Umm, well, uhhh, I haven't nagged at my clients enough in some situations to do such
or to setup an automated procedure. <smile>
it is very bad practice (imnsho) to se4t the
compact on close flag to true.


Thanks for the detailed answer. As always your explanations are very interesting
and useful.

I do have some code which does it's own compact on closing and keeps the last ten
daily backups around. I was going to add some code which kept x weeks and y months
worth around as well.

I should also add some code which saves the record count by table when doing this
compact at the end of the day and compares it to yesterday and flags any anomalies.

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
Nov 12 '05 #13

P: n/a
Well thanks everyone, this is very interesting. I didn't say anything
till now because I had nothing to say - I forwarded this thread to the
man I'm working with and gathered from his response he's already aware
of the Jet and upgrade issues. I wasn't, and I have neither the
authority nor the expertise to mess with the Jet :0!

As it happens I don't have my back-end set to compact on close. I was
considering it at one point, but I just checked and it's not set. I'm
thinking maybe the times the error appeared to happen overnight, it
actually happened as we were closing it at the end of the day - but
that doesn't really explain much. It's good to know about the
drawbacks to compact on close - like so many things with microsoft if
you want it done right you have to do it yourself :D

I had been doing compact/repair(they're one operation in Access XP)
across the network without making a backup, I'm going to change that
now by making a copy and putting it on my C drive before I back it up.

Thanks again,
Julia

Tony Toews <tt****@telusplanet.net> wrote in message news:<bg********************************@4ax.com>. ..
Peter Miller <pm*****@pksolutions.com> wrote:
So it's rather interesting that this happened when you closed the MDB.


'compact on close' = true


And I never do this as I'm running multi user FE/BEs so this never even occurred to
me. <sigh>

Tony

Nov 12 '05 #14

P: n/a
jb******@oldrepublic.com (Julia Baresch) wrote in
news:50**************************@posting.google.c om:
I had been doing compact/repair(they're one operation in Access
XP) across the network without making a backup, I'm going to
change that now by making a copy and putting it on my C drive
before I back it up.


You should never compact any MDB without a backup, no matter if it's
across a network or locally, because the resulting new MDB could be
damaged or incomplete because of corruption in the original. But the
original may retain enough information to recover your data.

Never, ever, compact without a backup, unless you can afford to lose
the MDB.

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

This discussion thread is closed

Replies have been disabled for this discussion.