|
vb123.com |
|
|
Home Contact Us Order our Software
RSS &
Newsletter
Get Good Help
Is Your Database
Corrupt ?
DryToast Garry's Blog Like FMS Products?
About The Editor
Garry Robinson
writes for a number of popular computer magazines, is now a book author
and has worked on 100+ Access databases. He is based in Sydney,
Australia or try our new site built with
SharePoint Designer |
The
The Toolbox
Probably the most vulnerable part of developing Access solutions is the developer. I personally am a little obsessed with cleaning up those objects in my database that just didn't work out. This routine occasionally leads to yours truly deleting the wrong object. Also, sometimes I will misunderstand a client's suggestions and make irretrievable alterations to a form or a module. So how do I get back to a previous point in the development cycle?
The answer is easy, and developers have used it since the beginning of computer time. It's called versions, and it's very simple to do. After you've made a number of alterations and you're happy with those changes, you give the database a version number. This number generally will be sequential and may involve major and minor version numbers or letters. For our business, we use the following procedure for front-end databases:
-
Update the version number on the startup form.
-
Save the database to a .ZIP or other type of compressed file with the same name as the database and a .ZIP file extension.
-
Rename the .ZIP file to include the version number.
| Tip |
Always remember to make a brand new .ZIP file and then rename it. This action will ensure that you won't send the wrong version to a client. I once made the mistake of meaning to add a database to an existing .ZIP file but goofed up. The previous version of a database then went to the client for them to add data. When it came back, I replaced the development version with the client's older version. |
To make a version archive, first make a new .ZIP file of your database, then rename the file to the version number shown by the files already in the folder (see Figure 5-3).
Figure 5-3: Adding the database to a .ZIP file.
With back-end databases, you have to be a lot more careful with managing both the changes and the archives because the client will have the latest data. What you really want to avoid is sending a copy of the back-end database back to the client and inadvertently having that file overwrite the live database. Always keep a copy of back-end databases that the client sends to you because the client could also have problems and might require a backup. Keeping multiple compressed versions of back-end databases whenever you change the data structure is a good idea. One exception to this rule is confidential information. You need to make sure that back-end databases that hold confidential information, such as credit card details, are not being stored on any computer other than those specially configured to protect that information.
| Tip |
Compression systems generally will have the option of a password. You may want to use a password when transferring files by email or when saving confidential or important databases in an archive. |
Find Out More
Click on the following button
These samples are discussed at
length in Chapter 5 of Garry's Book on Access
Protection and Security
Read More
You should also try out the simple backup process that comes with
the
Access Workbench
Alternative Access Protection/Security Ideas
to jump to the next page in the protection samples loop.