469,280 Members | 2,449 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,280 developers. It's quick & easy.

Unrecognized Database Format (Error 3343)

i have created a database for our advisors to log their call types. It is being run on about 10 different machines. Every couple of weeks, when someone tries to open it, the error Unrecognized database format <filename>. (Error 3343) appears. It cannot be repaired as it doesn't seem to recognise it as an MDB file. Can anyone tell me:
1) how do i stop this from happening
2)how can i repair the file, or at least recover the data to insert into a copy of the database

all help is greatly appreciated.
Feb 6 '07 #1
6 21773
Rabbit
12,516 Expert Mod 8TB
You're saying that it only happens every once in a while and to different people on different machines?

And that once it has happened, it may work if you try to open it again?
Feb 6 '07 #2
NeoPa
32,173 Expert Mod 16PB
Can you determine under which conditions this happens?
You've not given us much information to work with.
Have you googled the error number?
Feb 6 '07 #3
NeoPa
32,173 Expert Mod 16PB
You don't say what versions of anything you're using (POSTING GUIDELINES: Please read carefully before posting to a forum).
After googling a little I would guess that installing and using the latest versions of the software (DAO etc) on all of the PCs may help to resolve your issue.
Feb 6 '07 #4
Apologies. The machines are running on Windows NT 4.0. Access version '97. I tried to google the number and didn't get anything.

The error seems to happen without reason. The first couple of times, it happened when i came in first thing in the morning. The database was ok the night before.

It has also happened when there are various users and they are using the program as intended.
Feb 7 '07 #5
NeoPa
32,173 Expert Mod 16PB
I'm sorry James.
I appreciate that you cannot always find more information, but with that information there's not much more I can suggest.
I assume you've been through all the earlier posts and tried out all of the suggestions given.
Alternatively (I can say this as you don't work in my company) you can try getting your IT department to help. It should certainly be a bit easier for someone who can get hands-on access to the situation.
Feb 7 '07 #6
nico5038
3,080 Expert 2GB
MS Access database recovery steps:

1) Create a backup of the corrupt database. (Just in case of)

2) Create a new database and use File/Get external data/Import to get all objects of the damaged database.

3) Try these Microsoft solutions:
Repair A97/A2000:
http://support.microsoft.com/support/kb/articles/Q109/9/53.asp
Jetcomp:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q273956
and/or read the article:
ACC2000: How to Troubleshoot Corruption in a Microsoft Access Database
http://support.microsoft.com/default.aspx?scid=kb;en-us;306204

4) Bit "heavier":
Access decompile:
http://www.granite.ab.ca/access/decompile.htm

5) Try a recovery tool / Table rescue
Table datarecovery:
www.mvps.org/access/tables/tbl0018.htm
Access recovery:
http://www.officerecovery.com/access/index.htm

6) Ask a company (will cost $$'s ! )
http://www.pksolutions.com/services.htm

check also: http://www.granite.ab.ca/access/corruptmdbs.htm

All databases are heavy network users. To reduce the risk of corruption, these are things to do for any database:

1: Make sure your hardware is in top shape, all computers are routinely vacuumed to remove dust and lint and your network is set up correctly. Have all the machines on the same domain.

2: Have individual front ends on each machine. I created a database that checks the server for a newer copy of the front end, downloads it if needed, then runs it. You can get a copy of it at: http://www.nosuffering.com/Nelson/CheckForUpdatedFe.zip

3: Create a mapped drive for the backend or place the backend folder as close to the root folder and use only UNC path to the backend. Some people (and Microsoft) say the mapped drive is better, some say the UNC path is better. I have found it depends on the network setup.

4: Have the name of the backend and the name of the folders in the UNC path to it as short as possible meeting dos 8.3 naming specs and with only alpha numeric characters. \\server1\C:\db\db1_be.mdb is better than \\Database Server 601\C:\My Database Folder\Database Backends\My Database Backend_be.mdb

5: Don't run a local copy of the front end on the machine that has the backend -- best to have the backend on a server.

All of this is cutting down the number of times accesses need to be qualified, files need to be opened and closed and reduces the complexity of parsing the path all of which reduces the chance of corruption.

Nic;o)
Feb 7 '07 #7

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

1 post views Thread by Rabbit | last post: by
4 posts views Thread by HeislerKurt | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.