Object type and dictionary problems
Fixes for GeoDin object type and dictionary errors - missing object types, dictionaries that fail to load, and standard-change hazards.
Last updated
Was this helpful?
Fixes for GeoDin object type and dictionary errors - missing object types, dictionaries that fail to load, and standard-change hazards.
Symptom-first fixes for errors caused by missing or mismatched object types, dictionaries, and data types - most common when opening a database received from a third party. Background: Object types and Dictionaries.
The database references an object type your installation does not have. If it is a standard object type and you are online, click Install in the message to add it in its standard-delivery state.
Databases received from third parties often carry modified dictionaries or signatures, so the standard install may still not match. Best practice: ask the database provider for their system files as well - either their SYSLIB folder or the exported object type. With their SYSLIB you can either install the missing object type from it, or keep a second, parallel GeoDin installation that uses their SYSLIB unchanged (copy your installation folder, rename it, and swap in the provided SYSLIB), switching installations per database instead of reinstalling object types each time.
Usually caused by missing data-type dictionaries. Click OK - the database and project still open, but edits to fields whose dictionaries are missing will not save.
Often the culprits are data types that are registered in the database but not actually used. To remove them:
Open the database and confirm the message with OK.
Start the Datatype Manager from the method list.
Click Determine number of records.
Select the data types showing 0 records and remove them with Remove data type.
If the message persists, ask the database provider for their SYSLIB folder or exported object type and data types, as with the missing-object-type error above.
The 9.0.6/9.0.7 releases of the EN ISO 22475 object type renamed the geotechnical data-type short names (PSD, OED, UUT, and others) to avoid clashes with the Location [G1BORLOG] object type, and require GeoDin 10.1 or 15.
Back up your SYSLIB and data types before this update. If your database also uses Location [G1BORLOG], custom parameters can be lost and the database correction is not automated for mixed cases - contact support first. Layouts and queries that reference renamed data types must be adjusted afterwards.
Switching the ground description standard on an object that already has layer data can regenerate the description and remove layer entries below the change. Back up before changing the standard on existing logs, and verify the layer data afterwards. If you need to migrate logs between standards, contact support for the recommended route.
Last updated
Was this helpful?
Was this helpful?