Your goal as a database developer is to provide adequate protection without imposing unnecessary restrictions on the people who should have access to your database. The type of security required to protect a database depends on how many people are using it and where it is stored.

You can encrypt a database, which does not prevent it from being opened and viewed in Access, but does keep people who don’t have a copy of Access from reading or making sense of the data.

You can assign a password to your database, preventing unauthorized users from opening it.

You can share a database on a local area network (LAN) and limit what users can do with the database by using the same network security you use to protect other information on the network. To prevent multiple users from attempting to update the same record at the same time, you can implement pessimistic locking, which locks a record for the entire time it is being edited, or optimistic locking, which locks a record only for the brief time that Access is saving the changes.

You can convert your database to a new version, called a Design Master, and then create replicas of that master database to distribute to remote locations. The replicas can then be synchronized and changes merged with the master database. After all changes have been recorded, all of the replicas are updated with the current information from the Design Master and sent back to the remote locations.

You can split your database into a back-end database, containing the tables, and a front-end database, containing the other database objects. You can store the back-end database on a server and distribute the front-end database to all the people who work with the data. They can use all the objects that you created (other than the tables, which are not available for editing), or create their own.

You can control the access of individuals or groups to your entire database or to specific objects in it by implementing user-level security. You can create new workgroups and add groups, users, passwords and permissions to each workgroup. All this information is stored in a Workgroup Information File (WIF) that you can easily generate by using the Security Wizard. After the workgroup has been created, you can either use workgroup commands to maintain it or run the Security Wizard again to modify the WIF.

If you have added VBA procedures to a database, you can protect your VBA code with a password, or by saving the database as a Microsoft Database Executable (MDE) file. If you set a password for the code, it remains available for editing by anyone who knows the password. If you save the database as an MDE file, people using the file can run your code, but they can’t view or edit it.