Error: Unrecognized Database

[evictme]

I believe I figured out the culprit. Me (My computer). Im running a Windows 11 Pro Pre-release build. I think recreating databases (FE/BE) on my computer and then distributing them for users (All on Windows 10 Pro) was causing the issue. Today I recreated both database files on a windows 10 Pro PC and distributed. I am hoping this will mitigate the issue. I believe it will but Ill keep you all posted.

I have since changed my distribution method to the batch file example from an earlier post by @Pat Hartman (Thank you!). I used 2 .bat files, one that runs the main .bat file from example but minimized so the users do not see any of the hotdog being made (they are easily spooked).

I am going to avoid running any of the database on my PC for now.

Thank you all for your help and insight, I will keep you posted.

Best,

- E

 

[evictme]

Sometimes helps that method :
01. Rename the corrupted database
02. Create a new (empty) database with the name of the old one
03. Import all objects from the old database to the new one
04. Check that everything has been imported and the relationships between tables are correct

Did all that, various times but on my Windows 11 Pro eval copy PC. I have now done this on a Windows 10 Pro PC. We'll see where this leads

 

[Eugene-LS]

I have now done this on a Windows 10 Pro PC.

I think that OS has nothing to do with it ...
If, for example, your network is "sparking" - there is nothing you can do - except change the network cable

 

[Pat Hartman]

Dave, I know you can build/update an .mdb/.mde with newer versions of Access. I was talking about the .mdw.

 

[gemma-the-husky]

@Pat Hartman

Ah. I see. It was this comment. But I take it you mean that as the OP does use an .accdb, he therefore has to keep converting backwards and forwards to use the .mdw?

But without an interface to add/change the user's security, how can it be useful? Wouldn't you always have to work in the mdb and then convert to the .accdb to make FE changes?

 

[evictme]

@Pat Hartman

Ah. I see. It was this comment. But I take it you mean that as the OP does use an .accdb, he therefore has to keep converting backwards and forwards to use the .mdw?

Yes. If I need to add a new person to the mdw (security file), I convert the BE to mdb. Run the security wizard to completion. convert back to .accdb and done. However, up until today our BE file has been mdb so the conversion was not necessary. But can confirm that that works.

 

[evictme]

UPDATE:

Since running the database and all the fresh copies from a Windows 10 Pro PC the only thing that has changed is that now, corruption continues to happen but does not give an error.

We do not see a "Unrecognized db or mdb file..." error. 2 of our key tables, tables we use the most (around 70K records) are causing corruption when users input. It seems to build up a ton of errors and then some of our database features just stop and when I go to check the backend and those 2 tables have corrupted records (mostly new or recently input), they have lost primary keys, and will show records but with #### symbols where the notes (long text fields) are.

Most entries are fine but then a bunch are not.

After renaming the notes table, I copy the design to a NEW table with the Name of that notes table (the old name), and Append from the OLD table to the new.

This seems to help a while but then we start getting corruption again.

Somethings you should know: I have 2 audit tracking tables and most of the time when something is edited or a new note is inputed, it will also update the audit table and send a record to another table indicating something new was entered but not the value/content.

Its driving me nuts because I have to shutdown users midday and in most cases we lost what they just inputted. Literally the 3rd time they will input the same thing we've lost in the past couple of days.

Another question:
Should I be using mdb for both FE and BE would this be the situation with the notes and creating notes values/records? Would mdb/accdb make a diffrence when it comes to Long Text (Rich Text) fields?

Why does this keep happening?

Thanks all.

 

[gemma-the-husky]

I don't know the technical answers. I think if you had things in the accdb that the mdb can't use you would not be able to create the mdb.

I know the html tags that give the special formatting in an accdb just get treated as plain text in an mdb.
Do you have mvfs? I could see those being legal in an mdb, and maybe causing issues.

I think my inclination would be to go to all accdb, but then you would have to code your own security features.. You could go to all mdb, but you would lose your rich texr fields.

Are all your users wired? Wireless connections can be a cause of corruption.

 

[isladogs]

ACCDB files are more likely to be resilient for example with memo/long text fields.
These often used to cause corruption in the MDB files created in older versions of Access such as 2003.

I haven't read the entire thread but has anyone suggested decompiling your project? If not, I would certainly suggest it.

 

[Eugene-LS]

for example with memo/long text fields.

You are close to the truth!
I have similar observations ...

Unfortunately, I don't have a clear answer yet.
MS kips silence to any questions, like a "Partisan in Gestapo", - "We are working with it" - they answers ...

 

[SHANEMAC51]

Would mdb/accdb make a diffrence when it comes to Long Text (Rich Text) fields?

I try not to have long fields (after all, this is an additional hidden table)

instead of using a MEMO field, I use a subordinate table with fields, maybe MEMO, but short enough that the active time of working with this paragraph would be relatively small

 

[SHANEMAC51]

Did all that, various times but on my Windows 11 Pro eval copy PC. I have now done this on a Windows 10 Pro PC. We'll see where this leads

I have seen the length of the entered text from 5000 to 11000 characters, with many adjustments

maybe the user entered this text all day and corrected it for several days, and the font is very small, almost unreadable

a subordinate table with fields of 255 characters and a larger font would be very useful