views:

184

answers:

3

Is there a way to programmatically check for database object corruption in Access 2003?

My development project has gotten complex enough that it's hard to manually check all the objects after a day of programming to see if some small control, form, report, query, or code object has been corrupted somehow. I already have the data split off into a separate SQL Database stored on another machine, and this project is merely a front-end application to work with the data.

Mostly an academic musing, as I just don't want to get so far - then have corruption put me back several weeks because some seldom used object got corrupted way back when.

Any ideas out there? Thanks in advance for any pointers!

EDITED 12/03/2009 @ 11:51

Sadly, I can only accept one answer - though I got a few very good ones, thank you for all the pointers!

+2  A: 

You might like to look at: http://stackoverflow.com/questions/244896/is-it-possible-to-programmatically-detect-corrupt-access-2007-database-tables

I am inclined to keep a copy of important databases at each compact & repair and to compare the new database against the previous one. You can also check for non-standard characters.

Remou
That posting only deals with table level corruption.
Tony Toews
no, not only. It also applies to form and/or module corruptions
Philippe Grondier
+1  A: 

Proper compilation practices will prevent corruption of the VBA project (which is what you're talking about here).

That entails:

  1. use OPTION EXPLICIT in all modules.

  2. turn off COMPILE ON DEMAND in the VBE options.

  3. compile your code regularly, while working.

  4. periodically (e.g., once a day after a full day of coding) decompile and recompile the code.

If you do this, you'll never encounter corruption in the first place so you won't need to test for it (which is impossible in the first place).

David-W-Fenton
I really do try to follow this regiment, though I guess what I was asking was if there was a way to search for, and detect corruption in forms, queries, or other non-table objects. I have had compact/repair utterly trash a database, so I have irrational fears about using it. Thanks for the pointers, though - each little bit helps!
Comrad_Durandal
Well, there are two separate issues, data corruption and code corruption. Compact/Repair has little to do with the latter, and I thought that was what the question was about. If your tables are getting corrupted, that's a serious issue that's caused by something external to Access/Jet/ACE, so you should try to track down the cause and rectify it. But you should never compact/repair or decompile without first making a backup.
David-W-Fenton
+1  A: 

Neither Compact/Repair nor Decompile/Recompile catches all corruption problems, although you should be doing this anyway.

I use a function to export all Container Docs (and QueryDefs) using SaveAsText into a date/time stamped folder, and use it regularly throughout the day. If I suspect any corruption, I create a new mdb, and use LoadFromText to recreate the objects.

maxhugen
Specifically, what kind of corruption problems can a decompile/recompile cycle miss? The only time I've ever seen decompile fail to fix corruption is when the user didn't do it right (e.g., running the code after the decompile but before the compact that would discard the old compiled code data pages).
David-W-Fenton
Now this sounds like it might help me, do you happen to have a copy of the function code to illustrate? Text documents are less space-consuming than entire copies of the MDB file for every day I worked on it - the IT people are already getting a little nervous about space on the network, and I don't want to get my 'pet project' canned for running the company out of space.
Comrad_Durandal
If you search this website on "SaveAsText" you get a whole host of discussions of it, and I'm sure there's code in there to do it. For what it's worth, I have never used it except for the occasional corrupted object (maybe 10 times in the 13 years or so that I've been programming in Access). The files are quite small, actually, much smaller in total than the Access MDB/ACCDB that they are generated from.
David-W-Fenton