Corrupted form/vba module

[Thomas Kroljic]

All,
I think I have a corrupted form/vba module. The form in question will not
recognize it's VBA form module. I've tried the following: compact and repair
database, exporting the form to a new database, removing the VBA module from
the new database then using copy/paste commands copying the vba module from
the original database and pasting to the new database.

There is a large amount of code behind the form in question, otherswise I'd
retype the entire module back into the new database. The form itself would
be very time comsuming to rebuild.

Any thoughts on how I can save this form and code? I'm using Access 2000
SP-3.

Thank you,
Thomas j. Kroljic

 

[MarkInSalemOR]

I'm not sure you can recover the VBA code at this point. I'm assuming since
it can't find it's module that you can't see the code. If you can find the
code a copy and paste into a new form should deal with it. As far as
rebuilding the form create a new form in a new database, abandon the mdb with
the corrupted form it's going to have more problems. Copy the controls on the
form and paste them into the new form. If it corrupts right away then copy a
few at a time until you find the offending control.

If you are on a network check if a backup has been run. You might be able to
recover part or all of you VBA code if a recent network backup has it.

You didn't mention using the decompile switch. I doubt it will help but it's
worth a minute to try. Go to the command prompt, enter the mdb path enter a
space and the switch /decompile. It should look something like this.

C:\>mymdbpath.mdb /decompile

I've found the only way to prevent this is to compact and repair daily or
more frequently if you mdb grows rapidly in development. I generally compact
when mine doubles in size. Or I've made some major changes to forms, tables
or queries (deleted, copied, renamed, deleted half-the controls). And backup
everytime you compact, back up the uncompacted database and then compact.
That way you have a back up if the compaction causes a problem. Keep the
backups until you finish development so you can go back to any stage if
needed because of an Access error or your own errors.

Note - go to the settings and click the display hidden objects and look
around in the tables it shows. You might find a save for your dilemna. Again
this is a long shot but it's worth a try.

Mark

 

[Kevin K. Sullivan]

Also, you can try the undocumented

Application.SaveAsText acForm, strFormName, strCompleteFileName

and

Application.LoadFromText acForm, strFormName, strCompleteFileName

I'd suggest saving the form to text and then loading it into a fresh
(uncorrupted) database.

HTH,

Kevin

 

[Thomas Kroljic]

Mark,
Thanks for your reply. During the day, I downloaded a utility called
JetComp.exe off the Microsoft website and ran this against my questionable
database. It seems to have created a new "clean" database from the corrupted
DB. So far I've gone through most of the forms that the end users would use
and they appear to work fine. I'll have to see what the fallout is over the
next day or two.

In the corrupted DB, I was able to see the VBA code, but for some reason,
when you ran the form, your get an error because the form somehow lost it's
connection or reference to the VBA module. Not sure if I'm stating this
correctly.

I usually run the compact/repair option twice a week at night time when no
one is on the system. My backend database will double in size in about a
week. Not sure why since there are not that many transactions being entered
into the db.

I've never used the /decompile switch. I'll have to read up on that one.

Thanks,
Thomas J. Kroljic

 

[Thomas Kroljic]

Kevin,
Thanks for your suggestions. I downloaded the JetComp.exe utility from
Microsoft and use this to create a new database from the corrupted one. This
seems to have worked (so far). I'll keep your "undocumented" suggestions
near by for future reference.

Thanks,
Thomas j. Kroljic