When you make a modification to a database, it usually means that you are modifying fields in the database. When you modify a database, you need to be careful. Concordance has no restrictions for database modifications, but we do offer recommendations on what you should and should not do so you are less likely to corrupt your database.
Always back up a database's files before you make any changes to the database. Some modifications are more dangerous than others. Database modifications always require a full index update immediately after the modifications. Most modify functions rebuild the database and erase the dictionary, requiring you to index the database from scratch. We recommend that you plan ahead to allocate time for database modification since it requires exclusive access to the database and time to run a full index.
Changes that do not require a database rebuild:
•Changing a date field’s display type
•Changing only one field’s name
•Adding or deleting key fields
When making changes, follow the 3 Change Rule. We recommend that you not make more than three changes to a database before indexing. After making three changes using the Modify dialog, save your changes, and then index the database.
If you have applied security, you must also give users access to any new or renamed fields before they are visible in the database. New and renamed fields are not visible in the Table view until they are added to the layout structure.
|
Modifications made to a database is a common reason for corruption. Please use caution when making changes and always back up your database files before doing so. Also it is a good practice to close other databases while making database modifications. |
|
If you are modifying the database structure and using an active sorting layout or table layout, you must delete .sortinglayout and .layout files. The files will be rebuilt to accommodate the new database structure the next time you open the database. |
|
If Concordance security is enabled, the Modify dialog can only be accessed by a user that has full read/write access to all fields. |
Risk |
Activity |
|---|---|
Less Dangerous |
Adding/removing punctuation |
|
Changing a field’s length |
|
Changing field properties (index or key) |
|
Changing data types (text to paragraph) |
|
Adding a new field at the end of the list |
|
Inserting a new field in the middle of the list |
|
Renaming a field – A common cause of database corruption! |
|
Delete or insert a field elsewhere – common cause of database corruption. |
More Dangerous |
Making more than one change to the same field, at the same time |
|
If you need to change a field name, make a new field first and run the AppendOneFieldToAnother_<version>.cpl, then hide the other field from users in the Security dialog box. Do not delete it! |
Modify a Database
1.Make a back-up copy of the database you are modifying. See Backup and Archive for more information. Do not proceed to step 2 until you have completed this procedure.
2.Once your database backup copy is secure, open the database you want to modify and close all other databases.
3.On the File menu, click Modify. The Modify dialog displays.
4.Make the necessary changes.
5.Click OK to save your changes and close the Modify dialog.
6.Run a full index.
|
Whenever you add or rename a field in the database, it is added to the database without field access rights. In the Security dialog box, the No rights check box is automatically selected for the field. You will need to set the field privileges for the new or renamed field for users already entered in the Security dialog box. For more information about field access rights, see Setting Up Security. |