As I've struggled and suffered through many a corruption issue in the past too, here are some thoughts...
1. Always split into a Front End (FE) and Back End (BE). I've never yet - touch wood - had a corruption in the BE data file. Even with many millions of records!
2. The 'corruptibility' of a FE doesn't seem to be affected by the sheer number of forms and reports. Instead, it looks like problems creep in when I have very complex forms &/or reports. I suspect this may be due to the way that Access stores these objects in the database. Perhaps this explains why some developers rarely if ever have corruption issues? I don't know.
3. I used to often create a new db as Remou suggested when I had probs, and hated it because I lost my Relationships layout. This improved when I discovered Stephen Lebans' method to Save/Restore Relationship Layout at
(thanks Steve). Now however, I rarely have to create a new db despite continuing periodic corruptions - see 'Modus Operandi' below!
4. Distribute the FE as an .mde - although the bulk of corruptions happen whilst developing, rather than when users are using the app, I
think it's more stable.
Modus Operandi
1. I always open the FE (for development) using the
/decompile switch, and then recompile the code.
This one step, I believe, has really reduced the number of serious corruptions.
2. At the
first hint of any 'odd little errors' as JoeAtWork mentioned, I repair/compact, close the FE and re-open it using /decompile. If you don't, and continue instead, it does get worse!
3. If I do run into a more serious corruption that's not fixed by (2), I'll initially try
JetComp as Ed2020 suggests. This sometimes fixes it, but often not.
4. If it's still corrupt, I follow Ed2020's steps 2-4: import all objects into a new MDB file, run JetComp, decompile. A few times I've found that I could not import some forms &/or reports. I feel that Access has somehow screwed up the definition of the object when it stores it. It may not be a form/report you've even recently worked on, but again, I feel it has something to do with the way Access stores the objects. The only way around this, I've found, is to rebuild the form/report from scratch. Copy/paste (where possible) helps speed this up somewhat.
As Access ain't Open Source, we can't tell what's really happening in Access's innards. However, I'm reasonably convinced that the regular use of the /decompile switch has saved me a
lot of corruption-fixing time.
Hope this is useful!
Max Hugen
Australia
![[sad]](/data/assets/smilies/sad.gif "[sad] [sad]")
I'm developing my first Access project, consisting of about 20 forms, security (To be done) and who knows how many lines of code. Haven't generated a single Access report yet, and end-users won't be allowed to interact with the tables directly. 