Intro

The present section describes how to create and use a file for automatic updating of a created database.

What can it be done for? If the developer of a database and its user is the same person, everything is easy in case there appears a necessity to make some changes in the database structure — for example, to add a field or a report. The developer opens a work database and adds necessary elements there. 

And what if a database is complicated, and its structure is developed by one person (you) and is used by another one (the user) or even many people worldwide? Each of them has his or her own records in the database. At some moment of time the existing structure stops suiting users and they decide to add some fields, reports and replace used formulas. In this case, there are several variants of solution for this task:

• To ask users to send their databases, make necessary changes and send databases back. However, if there are a lot of users or they store some confidential data, it will be very difficult to fulfill this task. 
• Make changes in your own database and send it to all other users with an instruction to perform Synchronization. This way is more convenient, however, if in this case it is necessary to update many components of the database (forms, reports, functions and so on), the user may make a mistake and update wrong components.  
• Create and send a file for updating. At that, for updating the user will just  have to open this file, and all necessary changes will be introduced in his or her database. Let's have a closer look at this way of updating.

Practically, updating is synchronization plus a script of updating that describes what elements of the database and in what way should be updated. Do not be afraid — you will not have to write a script for updating; it is created automatically on the basis of any performed synchronization.

Creating a file for automatic updating

To create a file for automatic updating, you will need two databases:

• The first one (let's call it current_db) — contains the current version of the database that we are planning to update, installed on the users' computers;
• The second one (let's call it new_db) — a new version with changes, to which you need update users' databases.

To create a file for automatic updating:

1. Open current_db. 
2. Select File->Import/Export->Synchronization.
3. As the second database, select new_db.
4. Perform synchronization to update the structure of current_db to new_db (import forms, reports, update scripts and so on — do whatever you need). For more information, see the Synchronization section.
5. On completing synchronization, click the "Save this synchronization as an update file..." button at the bottom of the synchronization window.
6. The window with settings for an update file will be opened. On the first tab, enter the headline of an update. It will be displayed to the user before the update is executed. On the second tab you can see what database components will be updated (that is, a list of actions performed at synchronization).
7. Click the "Save..." button and specify under what name a file for automatic updating should be saved. 

That's it. Now send this file to all users, and they will be able to perform updating of their databases to a new version automatically — by selecting it in the File->Update Database... menu.

Recording databases versions

Thus, in the paragraph above we have described how you can create a file for automatic updating for your users. However, the database changes, and it is necessary to update the database structure once again. Then one more time. It is good if all users are well-disciplined, but what can be done if some users perform the second update without the first one? For example, in the first update a form was added, and in the second update a report for a new form was added. At best the user will get an error message and at worst (if updates are more complicated) — the structure of the database may be corrupted. Though before every update a backup copy of the database is created, there may occur an unpleasant situation.

This question is solved by such parameter as version available for every database. For a new database a version is absent (there is an empty line).

Changing and recording versions is set in the update settings:

• Flag 1. If this flag is selected, the update file can be used only for databases having a specific version (let's call it version_from). 
• Flag 2. If this flag is selected, after execution of an update a new version will be assigned to the database (the version name is specified lower, let's call it version_to).

To avoid mistakes at updates, we strongly recommend selecting both flags and specifying both values.

At updating the database for the first time it is necessary to leave version_from empty, and in version_to specify, for example, "ver2". After execution of the update the database version will become equal to "ver2". At updating the database for the second time it is necessary to specify "ver2" in version_from, and in version_to, for example, "ver3".

When trying to run the second update for a database having any version other than "ver2", the user will get a notification on version mismatch, and the update will not be performed.

You can specify any names of versions you like, for example, upd_2008-04-20 or fix_a.

If an update is not a compulsory one and does not make critical changes in the database structure (for example, adds new records to a database), it is possible to disable setting of a new version (version_to).

In any case, you should seriously treat the question of keeping records on database versions if you have several users and are planning to support their databases, adding new options to them and modifying them in correspondence with users' requests.

Current version of a database is shown in the main window caption, in brackets: