Moving and Copying Databases

The procedures used to move and copy databases are slightly different for Microsoft Access and SQL Server databases. The principles of moving a database applies equally to copying a populated database.

An iBase system might contain several related databases, for example copies on laptops of a main database on a central server. In this situation, you might want to define the folder objects that are shared by all the databases before you create or copying the main database. You might also want to consider Database Subsets as an alternative to copying the database.

Note: For greater control over these folder objects, use the separately-licensed Schema Update utility; for details, see Handling updates to the schema and folder objects.

There are several reasons why you might need to move, copy, or rename a database and its security file. Among these reasons are:

Migration to a different computer or server
Providing a copy for use at another site or on a laptop
Warning: Consider using database subsets where only a portion of the records is required.
Routine backup

When you copy or renaming a database, you should select a name that uniquely identifies it within your iBase system and also when used with third-party iBase databases.

The procedures for moving or copying a database and its security file are different for Microsoft Access and SQL Server databases and are described separately in:

You always need both the Windows permissions to move the files, and the ability to log on in iBase Designer as an iBase Security Administrator. If you are moving an SQL server database, you also require an SQL Server login name and password for connecting to each of the relevant SQL Server instances.

Note: Each database records the location of the security file that protects it. Each database is secured by only one security file but there might be several databases secured by the same security file. There must be only one security file in any one folder. The folder should be shared and referenced by a UNC path.

Handling external files

Databases can make references to, or otherwise use, external files. Many of these files must to be moved or copied with the database:


External file	Description
Hyperlink fields	As file names given in Hyperlink fields within records. For a database with multi-user access across a network, good practice would mean that all such files are held in a shared folder and named in the field using a UNC path, such as: \\server\sharedfolder\Report99.doc. No action is needed if this is true and the shared folder is accessible to users of the database in its new location. If UNC names are not used, copy the files to a corresponding drive letter on the destination computer, as discussed next for a single user database. For a single user database, it is possible that the files are held on a local disk and named using a drive letter and local folder names, as in this example: C:\Artwork\House.bmp. You must copy these files to a similar location on the destination computer. This might not always be possible if there is a conflicting use of drive letters.
Support files	As support files, such as chart and report templates, held in the same disk folder as the database .idb file. You must copy or move these files if you copy or move the `.idb` file so that the files stay together in one folder.
Audit log files	As a log file with extension `.idl`, only present for an iBase Microsoft Access database. You can move this file if you want to maintain a single log file for the database. If you do not move this file, iBase creates a new log file in the new location.
Word Search index	As a Word Search index with extension `.idx`, only present for an iBase Microsoft Access database that uses Word Search. You do not need to move this file. You can use iBase Designer to create a new index file in the new location.

You must make and restore true binary copies of all files mentioned in this section, using any convenient method supported by Microsoft Windows. If all you do is make copies for backup and occasionally restore from these copies to the original location, there is no special iBase procedure to follow. The procedures for handling external files are the same for both Access and SQL Server databases.

Handling updates to the schema and folder objects

If you have a Schema Update license, you can keep the copies of a main database, for example held on laptops, in step with changes made to the main database. Changes could include the addition of new fields, new pick lists, or changes to folder objects such as import specifications.

To facilitate the maintenance of copy databases on laptops, you can mark the folder objects that you want to be able to update in the future as common folder objects. These objects can then be added to, updated and deleted from the copy databases— standard folder objects cannot be maintained in this way.

Common folder objects can also be used to facilitate the updating of data in a copy database. For example, you could:

Add import specifications and an import batch specification to the main database, and export the data from the main database to create import files for use with the import batch specification.
Mark the import specifications and import batch specification as common folder objects.
Save a template from the main database to give to your laptop users.
Each user applies the template to their copy of the database. This adds the specifications to their database.
Each user runs the import batch specification to load the new and amended records.

For further information, see Using Common Folder Objects.

After the move

After a database is moved, users must find the new location of any moved files. After users open a moved database, iBase records any change of connection file location in the most recently used (MRU) section of their File menu.

What happens in subsequent use depends on the relative positions of the connection and security files:

If the security and connection files are in the same folder, users see no change from behavior before the move.
If the security and connection files are in different folders, users see a Security File browser each time that they need to log on and must navigate to the security file. (Where possible, you should always keep the security file and database in the same folder.)