Error When Opening, Deletes VBA

[Weekleyba]

Can anyone help me out with this one?
This morning I open my database and I get the following popup,
"The database cannot be opened because the VBA project contained in it cannot be read. The database can be opened only if the VBA project is first deleted. Deleting the VBA project removes all code from the modules, forms and reports."
It shows "OK", "Cancel", and "Help" buttons for only the OK button works.
I did press OK and sure enough it deletes all VBA. Yikes!
I have back ups but the same popup appears.
To get out of it, I have to go through the Task Manager and end the task.

Can anyone explain what is going on here?

Thanks,
Brad

 

[isladogs]

In a word. Corruption.
The one you opened with the error is now unusable.
If you are unlucky, you may have permanently lost all your vba code

If you're lucky, one of the following will fix it.
Try decompiling a copy of a backup to remove any corrupted compilation code.
If it opens without error, recompile then compact and repair.

If that fails, try copying all objects to a new database

 

[arnelgp]

Chances is there is no fix unless you have backup or database repair tool.
Never edit the vba code written in 32 bit to 64 bit or vice versa. That is mostly the cause of vba codes being mis aligned and therefore being lost.

 

[Weekleyba]

Thanks Ridders & Arnelgp.
I will have to put together a new db since the latest one is unrepairable.
Fortunately, I have many back ups.
The only issue is retrieving all current data as the one db that got corrupted had some additional data that the others did not.
I tried just copy/paste my data from corrupt db to the backup but, that didn't work since I have autonumber ID fields.
I going to try to copy/paste the VBA from the backup to the corrupted db (which lost all the VBA).
As a last resort, I guess I'll build a new one.
I'm not an expert by any means with Access but sure do like learning it. That said, I sometimes wonder how far down the rabbit hole it goes...........

 

[isladogs]

It doesn't sound like you've tried DECOMPILING.
You should definitely try that.
It's very quick and can't do any harm in your current situation.
It's saved more than one database of mine in similar situations.

In case you aren't aware how to do this, see this link:
http://www.fmsinc.com/MicrosoftAccess/Performance/Decompile.asp

Suggest you implement a scheduled backup routine from now on.
At least once per day. More often if your system is mission critical.

It's also another reason to split your database.... even if you are the only user

 

[Weekleyba]

Hey Ridders,
I will definitely give that a try.
I wasn't backing up near enough, so I'll up that to daily.
And, I guess I need to learn how to split the database.
I'll let you know if the decompile does the trick.
Thanks again for all the great advice!!

 

[Weekleyba]

Well, the decompile did not work. It still opens up with the error message of which there is no way around.
Looks like I'll have to try something else.
I'll probably go back to one of my latest backups and re-enter any missing data.
Thanks again guys for the help.

 

[roadie3124]

<snip>
Suggest you implement a scheduled backup routine from now on.
At least once per day. More often if your system is mission critical.

Very sound advice.

It's also another reason to split your database.... even if you are the only user

I would go in stronger than that. In my view, "splitting the database" should never be required. You should always start a new project by creating two databases: "Data" and "Code". Never, ever, ever create an Access database system with data (tables) and program (everything else) in the same physical database. I look at it as a fundamental requirement.

I haven't looked at the Microsoft documentation about split databases for many years. It might have changed. I think they said that this is a feature that you can use. They didn't say how important it is. Luckily for me, I subscribed to comp.databases.ms-access in the mid 1990s.

Sorry for going on a bit, but it's so important.

 

[Weekleyba]

The downside to splitting the database for me are two fold:
1. Since I find myself still making changes a couple times a week to the DB, it's annoying for folks to have to upload the latest forms.
2. Loss of portability. It's difficult for the front end to find the back end via long distance. We find it handy to be able to take a copy of the DB in our pockets when we travel.

Yes, this may not be the most secure set up but, the advantages above are out weighing the risks at this point.

Once more, I did retain all the data during the last event, it was just the code that was lost. So I assume, this could happen with split databases as well, that is, lose your code when things become corrupt.

The biggest take away for me was too back up the DB daily not weekly as I was doing.

As always, thanks for all the input. I love this forum!!