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.
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 laptopWarning: 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.
Handling external files
|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.
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.
|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
You do not need to move this file. You can use iBase Designer to create a new index file in the new location.
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.
- 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.
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.
- 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.)