All Code is gone 3

[jreynold]

So i've been working on this database MSaccess 2003 and all my code disappeared. Gone. No modules, no class objects, there is nothing left.

I was working on a form, closed it, opened it back up and poof, no buttons worked. They didn't work because the code had instantly disappeared.

Thank goodness I backed it up a couple hours ago, wish it had been sooner then that.

Does anyone know what can cause this? I really don't want this to be a common occurence.


I have is split with user level security if that

 

[JoeAtWork]

Welcome to Access development. And people wonder why I advocate using anything else if possible.

Were you getting any odd little errors before this happened? Usually Access gives off a few "pre-quakes" before the big one hits. I.e. it starts with a few little corruptions, which grow into big corruptions. If you fix the problem when it's still small, you may stave off disaster.

 

[TheAceMan1]

How are ya jreynold . . .

Apparently you had no [blue]BackUp![/blue] or you wouldn't have started the thread. Just look at what a simple [blue]BackUp![/blue] would've saved you!

I hope someone comes along with a magical retrive solution . . . but I doubt it!

See Ya! . . . . . .

Be sure to see thread181-473997
Also faq181-2886

 

[Remou]

I have found that when developing in Access, it is a good idea to create a fresh database fairly regularly, to keep very frequent back-ups and to decompile and repair often.

 

[galorin]

Or just do what I do, don't trust Access with data storage. 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.

My work gets backed up nightly, but the database is being stored on a MySQL Server residing on a robust RHEL server. That's how to do data storage.

 

[Ed2020]

One of the following *may* help you:

1. Compact & repair.
2. Import all objects into a new MDB file.
3. Download and run JetComp from microsoft.com
4. Decompile your MDB file.

At least it was only a couple of hours...

Ed Metcalfe.

Please do not feed the trolls.....

 

[jreynold]

Thanks for the support everyone! I quit on it and took the night off and am just getting back to this.

I am thinking I will just rework my 3 hours on the backed up pre crash database. Before I just start there though, how can I tell if my backed up copy is corrupt? I want to stave off another crash if possible.


TheAceMan:
I DID back it up, just not as frequently as i would have liked. I lost about 3 hours of work.

Remou:
Create a fresh database? Sounds like a good idea, but what do you do, export everything or... create a new .mdb and import everything?

Galorin: I have my tables in a separate .mdb backend and the end users (my employees) ONLY interact through forms. I have not gotten to reports yet.

Ed: I'm going to try your suggestions. Are these things that I should be doing on a regular basis while developing? Kind of housecleaning?

 

[Remou]

Create a new, blank database and import everything. You may wish to read:

http://www.granite.ab.ca/access/decompile.htm

and:

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

 

[Ed2020]

I may compact and repair occasionally whilst developing (but only very occasionally). The others I will only do if I have a problem.

I may just be lucky but I have relatively few corruption problems whilst developing (compared to the number some people report they have) and I've never had a major one that wasn't easily repaired in a production system even with upwards of eighty users. I have found that developing on a copy stored on my local drive to eliminate network connectivity problems helps a lot.

Ed Metcalfe.

Please do not feed the trolls.....

 

[maxhugen]

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

http://www.lebans.com/saverelationshipview.htm

(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

 

[Remou]

maxhugen
I believe you work a lot with '97? Importing relationships is not a problem with 2000+.

 

[maxhugen]

Hi Remou, yes, several apps are still in '97. Since I don't have to create a new db very often any more, I hadn't noticed that 2000+ versions now import the Relationships layout! Thanks for pointing that out.

Max Hugen
Australia