There are a number of other considerations with new database projects…
Do you want to restrict usage of the database? You can password protect a database to keep unwanted visitors from looking at your data.
You may need to go beyond simple password protection, however. Access has a feature called user level security. Each user logs into the database with their own user name and password (similar to the way you may have to log on to your network). Different users may be granted different access rights. Some staff may only be to read data, others may be able to enter new data but not delete anything, and others may be given full data access.
If you go with user level security, then you can also add another neat feature as well: usage tracking. You may print a report whenever you want that will reveal who has been using the database, what time of day a user logged in and out, and even which records a user modified. This can be extremely useful in discovering how employees interact with the database.
Do you intend to put the database on your network? How many people do you want to be able to access the database from their computers? How many users do you expect will have the database open on their desktops simultaneously? (Microsoft Access has limitations on the number of concurrent users that may open a single database file. Once too many people open the database at the same time, performance will begin to suffer.)
Do you want the ability to work directly with database backend objects to create custom queries and reports on-the-fly? Some users like to have a “database play area”, where they can interact directly with data while still being sure they won’t accidentally change table designs.
If the database is placed on the network and the network is already backed up on a regular basis, then backing up the database is not a worry. However, are you sure backups are consistently done on schedule? Are backup tapes taken offsite?
Backup procedures may be in place at your organization, but frequently it so happens that backup procedures are not followed on a daily basis as they should be. Performing backups can be time consuming and monotonous, and busy employees may let backups slide in favor of more pressing tasks. Even when backups are done on schedule, it sometimes happens that backups are not done properly and the errors are never discovered because backup checks were not established as a part of the backup procedure.
Even if your network is being backed up in a reliable way, it is still worthwhile to occasionally make backups of your own. Each backup is a snapshot of your data at a particular point in time. Sometimes data is changed and it is later discovered that the changes were erroneous. Having backups allows you to rewind the clock on the data.
If it seems desirable, a backup system may be included with the database. The database can even warn you when it’s time to make a new backup.
Now you’re ready for step #6, the final step…