Access 2010 db corruption (1 Viewer)

[revlisj]

Greetings,

Our company upgraded to Office 2010 about a year ago. Since then, both old and new databases become corrupt for no apparent reason. Various developers randomly receive the following error: "Unrecognized database format, database cannot be repaired or it is not a Microsoft access database file." A given database will be working fine one moment, then the next moment, maybe after saving a form or successfully compiling some code, the database is forced closed with an error. In many instances, the database changes cannot be recovered. Thus, we keep making backups every time we make the slightest database design changes. We are operating in a Windows 10 (64bit) environment. Our Windows patches are up-to-date. Our Access version is 14.0.7181.5000 (32 bit). HELP! Is this a known Microsoft bug? If so, is there a fix?

Cheers

 

[CJ_London]

Is this a known Microsoft bug?

No, but can be caused by not being set up properly.

As a starting point, is your db split? all data in a backend on a network server and all forms, reports, queries and code/macros in a front end, and each user uses their own copy of the front end located on their machine? If not, that is probably the reason for your corruption issues.

 

[revlisj]

Thanks for the quick response. Yes, the databases are split. The corruption message occasionally occurs when end users access a given database. But...most of the time the error occurs when a developer is in the front end make some sort of design change, even minor changes. The corruption has something to do with indexes within the database. I tried to isolate the issue by copying the front end and back end to a folder on my C: drive. I don't seem to encounter the error in this environment. I have a hunch it has something to do with networked/shared drives. It is very frustrating. Databases that worked for years, suddenly become corrupt.

 

[The_Doc_Man]

Is the affected developer of the FE linked to the "live" BE? That would do it. Your experiment of copying things to your local machine is actually the right answer.

You NEVER EVER involve live database files while developing. You need what we call a "design master" that will NEVER itself be published. When ready to publish a new version, you COPY the design master FE and apply production configuration changes to it. You NEVER publish the raw design master.

When you have to make changes to the BE, that gets trickier. You need to have down-time for the application because you need to rename the production BE to some place where a loose copy of the FE cannot automatically link to it. Then work on the copy of the BE to do the updates. Then and only then move the updated BE to the right folder. If the BE name doesn't change, then the FE copies will find it by path/name and will be happy again.

ALWAYS ALWAYS ALWAYS make backups of anything you put into production. Be meticulous in keeping a change history. Do whatever you can to track changes in a way that won't take forever to figure out what you did if something goes off the map. But never EVER allow ANYONE (including yourself) to "diddle" with a production copy.

I usually included code in the opening form such that if I detected that I was running a copy of the FE from the shared location, I immediately issued a nasty-gram message box and when they clicked OK, I forced an Application.Quit in a way that could not be avoided. (Among other things, that meant checking for open recordsets, forms, and reports, and forcing them to close, too... usually in that order.)

 

[NauticalGent]

We had a similar experience where I work. The original DB was developed in 2003 and once we "upgraded" to 2010, the bad "stuff" started.

The conversion occurred in 2014, two years before I came on the scene. To further confuse things, we also migrated from Win XP to Win 7.

The corruption has stopped but I cannot really say what has changed, except that I converted a lot of code that looped through record sets and updated tables - to action queries that allowed me to keep tables "less exposed"...I think so anyway.

One thing that became known to me was that during certain times, when these procedures were being run, users were forced out of the application until it had run its course. At some point this practice changed and users were allowed to be in the application while it was being altered.

I guess what I am saying is that it could be a combination of a few things and not necessarily something as major as a version change.

Not much help, I'm afraid, but best of luck to you in sorting this out.

 

[revlisj]

Thank you The_Doc_Man and NauticalGent! Our development environment contains isolated FE and BE databases. When making design changes to the FE, it is pointing to the isolated BE (no production stuff). Let's see what happens going forward. There doesn't seem to be a ironclad answer to this weird and sporadic issue.

 

[NauticalGent]

You're welcome! I want to validate Docs reply - changes need to be treated as an STD and quarantined from Gen Pop until it has been tested throughly in a controlled environment.

I get the feeling you already know this, I am simply beating this dead horse for the sake of others who may be reading this.

Take it from someone who has "caught the clap" and had to resort to liberal amounts of penicillin injections - administered where they hurt the worst!

 

[CJ_London]

As access matures it has become less tolerant of 'vague' code so errors that might have continued to execute in an older version of access will fall over in a more current version.

Examples include use of reserved words for field names (examples include date, time, desc, description, value). Also the use of dots and bangs ('.' & "!").

I would also look at your use of error handling

 

[Uncle Gizmo]

As access matures it has become less tolerant of 'vague' code

Hi Chris, I have noticed this too.

In particular, a controls default value, as in txtMyTextBox --- and in full:- txtMyTextBox.Value --- I note a couple of cases where it would be best to use the full qualification:- txtMyTextBox.Value

I'm currently gathering info for a blog about it.





Sent from my SM-G925F using Tapatalk

 

[jason_mag08]

there are various techniques to fix corrupt access database.
First is Compact & Repair inbuilt utility.\
Second Restore from recent healthy backup available.
Try, to import Access database file to newly created access database:
If trying these unable to fix. Have a look on essential techniques to repair ms access database: techniques-to-repair-ms-access-database.quora.com/