无法识别的数据库格式'filename.mdb' [英] Unrecognized database format 'filename.mdb'
问题描述
我在A2002机器上测试了在A2000中开发的FE / BE应用程序，并在退出应用程序时获得了此消息的
。单击唯一可用按钮确定，
按预期退出应用程序。
FE只是mdb，而不是mde。 FE和BE位于不同的目录中
在同一台机器上。
是否有设置，最好通过代码，我可以添加以阻止此错误？
感谢您的帮助。
Larry Mehl
< blockquote>" L Mehl" <我********* @ cyvest.com>写道：
我在A2002机器上测试了A2000开发的FE / BE应用程序，并在退出应用程序时收到此消息。单击唯一可用按钮确定，
按预期退出应用程序。
FE只是mdb，而不是mde。 FE和BE在同一台机器上的不同目录中。
是否有设置，最好通过代码，我可以添加以阻止此错误？
否。这是一种不寻常的情况。
当你在多个用户之间共享FE时，FE通常会被破坏。然而，当你说你测试过......时，听起来不像是b $ b。或者当用
打开另一个程序，比如Word，一旦自动保存命中，无法挽回地翻转
文件。
你退出MDB时也不应该得到消息。除非你在退出时做了一些非常不寻常的代码，可能会将一个opendatabase设置为
FE MDB
解释一下。在进行更新时，访问会暂时设置标志。访问
当用户在MDB中时，
不会检查此标志。打开MDB时，您应该只看到此
消息。所以当你关闭MDB时发生这个
是相当有趣的。
Tony
-
Tony Toews，微软Access MVP
请仅在新闻组中回复，以便其他人可以
阅读整个消息主题。
Microsoft Access Links，Hints，Tips&会计系统
http://www.granite.ab.ca /accsmstr.htm
我们自1月以来一直在我们的后端收到此消息，
所有用户在数据库中，还没有找到原因。它发生在第一周每天
，然后是随机的。通常在
天的中间，但至少一次是在没有人使用它的情况下一夜之间发生
（也许两次，我不能肯定） 。我们已经检查了不正确的
关闭和未经授权的用户，一无所获。只有当有人连接到后端时才会发出消息
- 打开
前端或合并文档。对于已经打开它的用户
似乎工作正常，但有时它会慢下来爬行。
要修复它我关闭并重新启动 - 打开后端，打开一条消息，打开它需要修复，我想修好吗？我说
是的，它会修理，之后就可以了，直到下次我们得到
的错误。
除非...有时.ldb文件挂起并且不会脱离。然后
它不会修复，因为它认为它仍然有用户（通常是我，并且
我知道我关闭了我的前端），我必须打电话我们的服务器人员
并且有人将其从服务器上删除。
我和2个技术支持人员正在研究这个问题。星期一我制作了一个新的
数据库文件并将所有对象转移到其中，但是星期二我们再次得到
错误。我们的DB技术向我发送了其他组的信息：
--------------------------- --------------------------
我也在同一个论坛发现了这个。所有这些都可以通过
来 www.dbforums.com
我只是做了一个带有Acces / VB系统的噩梦，我想它可能会
保存
别人也一样麻烦，如果我发布一些我发现的东西
而
修复它。
系统是Access 2000 MDB服务器上的文件和VB6
应用程序在客户端PC上运行
并通过ADO 2.6连接。对于
写的公司来说，这是至关重要的任务。前几天，第一个上班的人启动了他的电脑
而且它已经变得非常奇怪，然后似乎把它自己排除在外。 （这就是我能得到的全部
） -
这些人并不是黑客。）然后他开始申请了
并使用它开始
。不久之后，其他几个客户也开始了。然后
客户端是在bod机上关闭
，从那时起，只有客户
已经
连接将起作用。任何其他试图启动的客户都会在
Connection.Open阶段以无法识别的数据库格式错误
消息失败
。
然后我花了几个小时搞砸重新启动的分数和
服务器，
卸载并重新安装应用程序，安装Jet，重新安装
MDAC自己，
打开和测试连接，天知道还有什么。
所有人都不高兴。我终于确定数据库必须已经腐败了。我深吸了一口气，关闭了
最后工作的客户，发现还有一个LDB文件。我删除了
，并尝试了新的连接。相同的错误和（这很有趣）LDB
文件再次停留
，即使尝试连接失败。我在
Access中打开了MDB文件。它说
数据库需要修复。我说好了，它修复了它。
我的理论是在MDB
文件中有某种标题信息表明
是什么版本等等。当狡猾的机器断开连接时，这已经损坏了
这样，尽管那些连接起来的客户很好，新的
连接
失败，因为标题与ADO / Jet的预期不符。
当然，我是猜测因为这是公司喜欢的信息，因为这是微软认为的b / b
$ b最好保守秘密。我们不需要知道它是如何工作的，对吗？
----------------------- ----------------
这个：
这是我认为的相关内容。这个人无法摆脱ldb的
。
我也有类似的问题。我发现我可以将
权限设置为
更改，但必须确保db所在的目录
已设置不要
从它的父级继承权限。似乎每次新的
用户登录
a给定的机器，它搞砸了。
这里是另一个：
我有类似的问题，它与目录和文件有关
安全属性;
它不是'''''机器''问题，但''用户''具体问题。我不得不
将
目录和文件安全性更改为全部对于所有数据库用户。
和最后一些腐败指南。
一般来说......（尽管这可能不是新闻关于如何防止未来腐败的五大关键指标：
（1）确保前端表格是从后端表拆分 -
即
多用户情况永远不会让用户共享一个文件放在
网络上
包含表格和表格。
（2）永远不要通过网络压缩和修复数据库，总是在本地执行
。
（3）如果数据库已被放置在Windows 2000 Server上，请禁用
机会主义
锁定。这是一个技术问题，请访问
http：/ /www.datarevive.com/support/kb/kb2203.htm 了解更多
信息。
（4）检查或更换可疑计算机的网卡（错误的
网卡
a腐败的常见原因）。
（5）将最新的服务包/软件更新应用于Microsoft
访问。
另外， www.access-emergency.com （我们的竞争对手）有一些
优秀的文章
关于嗅探网络问题是腐败的原因，所以
这是值得的
退房。
--------------------- ---------
Tony Toews< tt **** @ telusplanet.net>在消息新闻中写道：< 96 ******************************** @ 4ax.com>。 .." L Mehl" <我********* @ cyvest.com>写道：
我在A2002机器上测试了A2000开发的FE / BE应用程序，并在退出应用程序时收到此消息。单击唯一可用按钮确定，
按预期退出应用程序。
FE只是mdb，而不是mde。 FE和BE在同一台机器上的不同目录中。
是否有设置，最好通过代码，我可以添加以阻止此错误？
<不是。这是一种不寻常的情况。
当你在多个用户之间共享FE时，FE通常会被破坏。然而，当你说你测试过......时，听起来并不像这种情况。或者当用另一个程序打开时，例如Word，一旦自动保存命中，无法挽回地翻转文件。
退出时你也不应该得到消息MDB。除非您在退出时执行一些非常不寻常的代码，例如，可能需要将一个opendatabase设置为FE MDB
要解释一下这一点。在进行更新时，访问会暂时设置标志。当用户在MDB中时，访问
不会检查此标志。在打开MDB时，您应该只看到此消息。所以当你关闭MDB时发生这个很有意思。
Tony
jb ****** @ oldrepublic.com （Julia Baresch）写道
新闻：50 **************************@posting.google.c om：
我们已经自1月以来我们在后端收到此消息，
与数据库中的所有用户一起，还没有找到原因。
你不喜欢不知道你正在使用哪个版本的Access，但是它在A2K中很常见
。
首先要检查的是你所有的工作站（那是所有的
他们，百分之一百，不是一两个）都有稳定的
版本的Access和Jet。这意味着：
1.不是原始版本的Access 2K - 你至少需要SR1a。
2.之前不是Jet 4.0服务包6 - 只有SP6及更高版本可以使用
。
重复一遍，每个工作站都必须是正确的
版。
我和一些
的客户一再经历过这种事情。这两个步骤总能消除这个问题。
但它可以重现（并且这样做），因为工作站有一个令人讨厌的习惯，即恢复到早期版本，因为他们被替换了
新的，Access重新安装，或其他一些应用程序
降级Jet 4.
最多我的A2K应用程序现在有一个登录例程，记录用户
名称，工作站，日期/时间以及MSACCESS.EXE和
MSJET40.dll的版本。当腐败发展时，我会看一下这张桌子并知道
究竟哪台机器需要修理。
-
David W. Fenton http://www.bway.net/~dfenton
dfenton http://www.bway.net/ ~dfassoc
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
"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
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
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
这篇关于无法识别的数据库格式'filename.mdb'的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
