so go back to your last back
re do the work from that last back up to the time you lost the db
failing that you may be able to import most/some/all of all the objects into brand new empty db.
failing that you may be able to recover some of the work using the decompile switch
moving on from that you need to develop strategies to either eliminate this or reduce the impact
...first and foremost develop a backup plan, stick to it, periodically prove that backup works
...separate development and live access files. NEVER do deisgn or development work on live data
...separate data (tables and common / generic queries) from the user interface (code, form, reports and user specific queries). this is the so called back end / front end split. when deploying a fornt end ideally each user should have their own local copy of the front end pointing to the same data
...front ends should be deployed as encrypted (MDE or ACCDE format not MDB/ACCDB format), theis means users cannot open the application and make changes to it.
...make sure your proposed use meets with the limits of Access
...that means run over a local network
...no bigger than 2Gb
...ideally no more than 15..30 concurrent if you are using the default database engine JET as opposed to say a client server backend
if its multi user make certain you the most appropriate form of record locking.
..Im sure there's other points you may need to consider, and no doubt someone else will be along to point out those I've missed
I'd rather be riding on the Tiger 800 or the Norton