Pre-Migration Data Integrity Constraints

This section lists constraints that can be encountered during a pre-migration data integrity check. While the migration wizard contains default actions for these types of constraint violations, you may wish to manually modify the appropriate data in the source database before performing the actual migration.

toc_vol_fk

Every document in a Laserfiche repository must be associated with a volume. In this situation, a document in the Toc table is referencing an invalid (non-existent) volume.

The migration wizard will not migrate any documents that encounter this constraint. An entry will be added to the migration log that informs the user that this constraint was encountered. The log entry will also display the affected documents by their TocIDs. If you believe the listed documents still contain valid data that you would like to save, create a new volume and then view the Toc table of the source SQL database. For those documents with TocIDs listed in the migration log, modify the value stored in the VolumeId column to reference the new volume.

toc_propset_fk

A document in the Toc table is referencing an invalid (non-existent) template. The migration wizard will migrate these documents into the new database. However, these documents will no longer be associated with a template.

toc_parentid_fk

A document in the Toc table is referencing a non-existent parent folder. If this constraint violation occurs, the migration wizard creates a folder named "Orphaned" in the root folder of the migrated Laserfiche repository. Any documents with an invalid parent folder will be placed in the Orphaned folder.

toc_name_ck

An entry in the Toc table has no name. Entries must have a name. The migration wizard renames any such entries to "Unknown" during the migration process.

vol_name_ck

A volume in the Vol table has no name. Volumes must have a name. The migration wizard renames any such volumes to "Unknown" during the migration process.

doc_pagenum_ck

Pages described in the Doc table cannot have a negative page number. For example, it is illogical for a page in a document to have a -1 page number. If such an entry exists in the source database, the migration wizard will not migrate any pages that have a negative page number.

If you believe any such page still contains valid data, open the Doc table and modify the negative numbers in the PageNum column. Be aware that the PageNum value should also be unique for any single TocId, as documents should not have multiple pages assigned the same page number.

doc_unq

Each page in the Doc table must have a unique TocID and PageNum. This constraint prevents a document from having multiple pages that are the name page number. For example, it is illogical for one document to have multiple page 1s. In such a situation, the migration wizard will only migrate the first such page encountered.

Warning: Each page in a volume must be associated with a unique StoreID. Be aware of this restriction if you decide to manually resolve a UNQ_Doc constraint violation. Improper modification to the Doc table can result in data loss. Edit the Doc table so that no document has multiple pages assigned the same page number. The migration wizard will display the TocID value for the document in question. Query the Doc table for the TocID specified and make sure no values are duplicated in the PageNum column.

doc_tocid_storeid_unq

Each page in the Doc table must have a unique combination of TocOID and StoreID. This constraint prevents a document from having multiple pages that point to the same volume image/text file. In such a situation, the migration wizard will only migrate the first such row encountered. If you are certain that the additional pages reference other storeIDs, you may want to modify the value to the appropriate StoreID. However, make certain you do not duplicate another row, as multiple pages referencing the same StoreID can corrupt your database.

pset_props_pos_ck

A field described in the TFields table cannot have a negative position in the template. For example, it is illogical for a field to be in the negative-first position in a template. The migration wizard will migrate any such fields as an independent field in the migrated repository.

prop_type_ck

A column in a TDx table is specified as an invalid data type. The migration wizard will not migrate any such entry in the TDx table. The associated entry will also not be migrated in the TFields table.

Edit the design of the TDx table so that the columns are of a supported data type. The following data types are considered valid: nvarchar, varchar, int, smallint, and datetime.

propdef_unq

As of Laserfiche 8, fields are globally unique objects where one field can be assigned to multiple templates. This means that each field must have a unique name from all other fields. If the migration utility finds multiple fields with the same name in the source repository, the first field will retain its original name. However, the migration utility will automatically append a incrementing integer to any subsequent fields with the same name, such that the second field becomes “FieldName (2),” the third field becomes “FieldName (3),” and so on.

The migration utility does include the option of automatically merging fields that satisfy specific conditions. You can enable this option from the Advanced Options dialog box. Fields can be merged if the following properties are all identical:

If all conditions are satisfied and you have enabled the field merging option, a new field is created and added to every template that contained one of the matching source fields. The width of the merged field will be the widest value of all the matching source fields.

List fields will never be merged automatically by the migration, but can be merged manually in the Administration Console after the migration is complete.

prop_name_ck

A field in the TFields table has no name. Fields must have a non-blank name. The migration wizard renames any such fields to "Unknown" during the migration process.

pset_name_ck

A template in the Tstr table has no name. Templates must have a non-blank name. The migration wizard renames any such templates to "Unknown" during the migration process.

trustee_name_ck

A trustee in the Users table has no name. Trustees must have a non-blank name. The migration wizard renames any such trustees to "Unknown" during the migration process.

item_id_ck

An annotation described in the Ann table is associated with a negative ItemID value. This is not logical, as pages cannot have a negative number of annotations. The ItemID value must be greater than 0 and must also be unique within the page that the annotation is on. For example, a single page cannot have two annotations with the same ItemID.

The migration wizard will not migrate any annotations that have a negative ItemID value. If you think the annotation is a valid annotation, modify the value in the Ann table to no longer be a negative value. Also make sure that the value is unique and that it is the next consecutive value following the last annotation for the page.

stamp_name_ck

A stamp in the Stamp table has no name. Stamps must have a non-blank name. The migration wizard renames any such stamps to "Unknown" during the migration process.

tag_name_ck

A tag in the Tag table has no name. Tags must have a non-blank name. The migration wizard renames any such tags to "Unknown" during the migration process.

watermark_ck

The text of a watermark in the Watermarks table is blank. The migration wizard sets the text of any such watermarks to "Unknown" during the migration process.

coff_name_ck

A cutoff instruction in the CoffCrit table has no name. Cutoff instructions must have a non-blank name. The migration wizard renames any such cutoff instructions to "Unknown" during the migration process.

disp_sched_name_ck

A retention schedule in the RetChed table has no name. Retention schedules must have a non-blank name. The migration wizard renames any such retention schedules to "Unknown" during the migration process.

event_name_ck

An event in the Events table has no name. Events must have a non-blank name. The migration wizard renames any such events to "Unknown" during the migration process.

location_name_ck

A location in the Location table has no name. Locations must have a non-blank name. The migration wizard renames any such locations to "Unknown" during the migration process.

For more information on a specific upgrade or migration topic, return to the upgrade and migration home page.