vb123.com.au
Creating Compressed (.ZIP) Archives
of your Access database
This is a sample from the
Microsoft Access Protection book by Garry
Robinson
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
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
Other Pages At VB123.com That May Be Of Interest
Alternative Access Protection/Security Ideas
Upper and Lower
Case for Access DatabasesClick on the following button
to jump to the next page in the protection samples loop.
Our Tools and Resources
vb123 Professionals
Get Good Help Here
If you need help with a database or
Office programming,
our Professionals could be the answer because we have worked on many
similar solutions
Frontpage Conversions
We have converted vb123.com to Expression Web,
contact us if we can help you move to the latest Microsoft web tool.
About The Editor ~ Contact Us
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
Access 2003 Security
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
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
Other Pages At VB123.com That May Be Of Interest
Alternative Access Protection/Security Ideas Click on the following button
to jump to the next page in the protection samples loop.
Our Tools and Resources
vb123 Professionals
Get Good Help Here
If you need help with a database or
Office programming,
our Professionals could be the answer because we have worked on many
similar solutions
Frontpage Conversions
We have converted vb123.com to Expression Web,
contact us if we can help you move to the latest Microsoft web tool.
About The Editor ~ Contact Us
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
Access 2003 Security
