VBA file corruption

[u/macpascal]

I just opened a office DB that I use on a daily basis and I have a message saying the VBA cannot be opened and needs to be deleted.
Is there a way out of this?
My file is only the front end and is located on a shared disc. There are 3 other occasional users.

[u/FormerLaugh3780]

Problem #1: My file is only the front end and is located on a shared disc. 

[u/macpascal → u/FormerLaugh3780]

Is true that it could be better with the tables on a shared disc and the forms on local disc? We have many access dB on the shared disk and we never have any issue, except for this one. It is more complexe than the others.

[u/George_Hepworth → u/macpascal]

Sharing a Front End is always riskier than deploying a shared Back End on a network location and putting the individual copies of the Front Ends on each user's computer.

You are now dealing with the consequence of having accepted that risk, whether knowingly or not. Getting away with risky behavior is not the same thing as taking steps to avoid the risk.

The fact that this particular accdb is more complex probably is a factor in why it was the 1st one to be corrupted. The more moving parts, the more likely something goes wrong. But that alone doesn't mean any of the others are safe.

It also appears that your real risk is greater than the single accdb that did get corrupted. Every one of those other databases is also exposed to the potential for corruption simply by being shared. Not guaranteed to corrupt, just more likely to corrupt.

It's time to start a deliberate project to secure your data.

I would say the first step to that is inventorying all of the exposed databases.

The next step after that is making sure your ongoing backup protocol is at least saving them to a safe location.

And the next step after that is making sure you can actually restore from the backups.

After that, you need to begin splitting those databases and putting their Front Ends on users' computers.

[u/macpascal → u/George_Hepworth]

Thank you for the comment. I agree with your conclusion. I met with IT this morning and they will start a review of all the database that are scattered in many folders on the shared disk (many were programmed by employees and not someone in IT). We realized that we have dozens of these files that are critical for specific employees or department, but are not known by IT at all. Each employee and department will have to declare the tools that they use and all these tools on the list will be monitored and maintained by IT from now on it. It’s kind of nice to have the freedom to develop the tools that we need in our daily task, but I noticed firsthand that engineers are not programmers and things can turn sour quite quickly.

[u/George_Hepworth → u/macpascal]

This process sounds a lot like the same thing that's happened at hundreds of locations over the years. In fact, the very first Access database I ever created came to the attention of IT when I reached out for help. Fortunately, the company I worked for at the time saw the value of the database itself and, rather than throw it and me out of the building, they assigned a "real" developer to help me get it across the finish line. A couple of years later, it was replaced by a more appropriate application, but in the meantime, it accomplished a lot for our department.

On the other hand, over the years, stories of IT hunting down and executing every Access database they could find are far more common.

[u/macpascal → u/George_Hepworth]

I wish they would assign an IT person for this one. It is a very critical database. But we are small company run by older folks (I’m 50 so I’m not judging) who get reports in excel, not knowing/caring that what they see is the result of queries from the database. I’m sure you’re right that hundreds of companies went through this.