Creating Compressed (.ZIP) Archives


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:

  1. Update the version number on the startup form.

  2. Save the database to a .ZIP or other type of compressed file with the same name as the database and a .ZIP file extension.

  3. 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).

click to expand
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.

Now I will review how you can use database compacting to back up your databases.




Real World Microsoft Access Database Protection and Security
Real World Microsoft Access Database Protection and Security
ISBN: 1590591267
EAN: 2147483647
Year: 2003
Pages: 176

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net