vb123.com

Garry Robinson's Popular MS Access, Office and VB Resource Site

 

Home  Contact Us
Order our Software


 Smart Access  
The Magazine that Access Developers loved to read and write for is back
Article Index Here or Read More

See 2010 Specials

RSS & Newsletter  
Join our XML/RSS Newsfeed or sign up for our informative newsletter on Office Automation, Access and VB topics
Read More

Get Good Help
If you need help with a database, our Professionals could be the answer
Read More

  The Workbench  Find out who has your database open, start the correct version of Access, easy compacting and backups, change startup options, mde compile,  shutdown database Read and Download

Access >>> SQL 
Upsize to SQL Server 2005 or 2008, easily repeated conversions, highly accurate SQL query
translation and web form conversion.
Read More

 Is Your Database Corrupt ?
If you have a corrupt database, Try our Access Recovery service

The Toolbox
Libraries of software that we regularly import into our projects. This is a newer version of the Toolshed More..

SharePoint
For our company file sharing and task management, we use
SharePointHosting


Datamining/Graphs

Explore your data with this versatile graphing and data mining shareware tool.  Read More

DryToast 
Backup and query your BaseCamp
® projects
Read More

Garry's Blog
Find out a few other things that Garry has been writing about Microsoft Access. Read more

Like FMS Products?
Purchase them from us and get a free Workbench or Toolbox  More

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
Contact Us ...

Search ...

or try our new site built with SharePoint Designer
 vb123.com.au
 

 

Next Tip  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:

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


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 Databases

Click on the following button Next Tip to jump to the next page in the protection samples loop.

 

Links >>>  Home | Search | Workbench | Orders | Newsletter | Access Security | Access professionals