If you simply rename your FE from accdb to accdr, what if someone renames back from accdr to accdb? They got access to everything even VBA code too?
As I said, this was for MY convenience for an internal application. Most applications are internal. I.e. written by and for the same company. That means that the intellectual property is not yours anyway. It belongs to the company that hired you to do the work. Renaming the FE is just a trick but it keeps people from accidentally getting into design view should they open the FE using the full version of Access. Access is not at all secure, no matter what you do. Therefore, you need to do what you can to prevent accidents. But, sabotage or theft is a whole different matter.
Nothing you can do is going to protect you from the catastrophe you described. Normally Access developers are not responsible for network security or backups or things like that. You just develop the application and other, more specialized people take care of the environment. If you find yourself in a situation where you do not have people to secure the environment, then at least some of the burden will fall on you because YOU are the person who knows the danger. Therefore, YOU need to ensure that backups are automated and at sufficiently frequently intervals to ensure the minimum data loss. Do not leave this to chance.
Insist that the company/client purchase software and then set it up for them. FMSInc.com sells useful software for Access applications. Explain the problem and the liability. Backups are like an insurance policy. They are a price to pay so you can start over from a rational place should there be a loss. So, you need to ensure the backups run as scheduled. You need to ensure that a sufficient number of images are kept. Eight dailies and 13 monthlies are a bare minimum. You should probably have several annual backups also. AND all backups need to be backed up off site. I use Carbonite for this. It backs up my home computer. Every time a file is saved, it is backed up within a few hours as Carbonite works in the background. Then you have to do some trial runs to make sure you can get to your local and remote backups and restore from them. The reason for having so many is because occasionally a user will delete something and realize later that it was a mistake.
You will then have to search through the backups until you find the last saved version of the data so you can restore it. You wouldn't restore the entire table or database, just a record or two so it is a completely manual process. Or even worse, you might find corruption and have to go back more than one backup to get past it.
Then there are a couple of techniques you can use with how you name directories that will keep people from accidently browsing to your important files - like the BE and the master copy of the FE so that they can't be accidentally deleted. The files can also be secured so that only certain people have the proper credentials to actually delete them.
The distribution method I use distributes a fresh copy of the FE each time the user clicks on his shortcut. We can discuss that separately if you start a new thread.
For my own personal Access work, I include automatic backups in all my FE's. They are hardcoded with my userID. So if I am the one who opened the app and some object was changed, they ask when the db closes if I want to make a backup. I make two types. One is just a copy of the FE .accdb and the other is an export to text of all objects EXCEPT tables. I allow these to accumulate and clean them out every month or so but back ups of major version releases longer. Think of these as "monthlies' or "yearly's".
support.microsoft.com
