CDFLIB Version: 2.9
Back to:
Catalogue Description Files (CDFs) are used by the LEA applications Dougal (Catalogue Designer) , Florence (Catalogue Builder) and Dylan (Catalogue File Registration). CDFs describe the structure of a data catalogue, which can be used to create and manipulate database tables which store the catalogue. CDFs use the Lynx Exploration Archive Objects defined for different file categories
Catalogue Description Files are used to map catalogues containing information about LEA Objects into database tables.
Catalogues can be stored in any database format supported by LEA Applications - currently Oracle and dBASE - see Using Databases in LEA Applications - and provide a standard mapping between the abstract attribute types defined in the LEA Object, and the field-types supported by the different database formats.
Database tables created from CDFs will use the field types listed below:
| Oracle Type | dBASE IV Type | |
|---|---|---|
| STRING | where x is the specified maximum string length |
where x is the specified maximum length, and must be less than 254 |
| INTEGER | Integer fields are stored with a width of 20 digits |
Integer fields are stored with a precision of 20 digits. |
| FLOAT | where x is the field precision, maximum precision is 18 |
where x is the field precision, maximum precision is 18 |
| DATETIME | DATE | Date/time values are stored as strings in a the LEA locale-independent format (see LEA Objects - Locale Independence) since dBASE has no combined date and time field type. |
| TRUEFALSE | CHAR(1) Oracle has no boolean type. Standard practice is to map boolean fields into a 1-byte CHAR field |
L (Logical) |
Catalogues stored as dBASE tables on disk are suitable for low-volume single-user systems. LEA Applications will load dBASE catalogues into a temporary Firebird database (see Using Databases in LEA Applications - Firebird embedded database) to enable the records to be manipulated with standard SQL. When changes are committed, the dBASE table is re-written to disk.
The CDF Layer Type is used to enable the Location Reconciliation and Spatial Loading functions of LEA Cataloguing. The Layer Type is used to define the type of shapes (POINT,LINE,POLYGON) and destination layer to resolve to when loading data into a spatially-enabled database or GIS project.
Multiple CDFs can share the same Layer Type, even if their underlying LEA Objects are different. For example, you could define a CDF called SEISMIC_MIGRATIONS based on the SEISMIC LEA Object, and another CDF called SEISMIC_REPORTS based on the DOCUMENT LEA Object. Both these CDFs can have a Layer Type of SEISMIC_2D because both will use the same location information, and would be linked to the same layer in a spatail database or GIS.
Layer Types are defined in the Oracle table LYNX_LAYER_TYPES. For loading to a spatially-enabled database (see Zebedee), this table must be present, must be acessible as a public synonym. This table defines all valid Layer Types for your spatial database.
The following script will create this table
| Column Name | Constraint | Comments | |
|---|---|---|---|
| LAYER_TYPE | varchar2(30) | primary key | Unique name for a layer with a particular set of business attributes. This is used in DOUGAL to set the CDF LAYER TYPE |
| DESCRIPTION | varchar2(200) | ||
| SHAPE_TYPE | varchar2(10) | check (SHAPE_TYPE in ('POINT','LINE','POLYGON')) | Intrinsic geometry type of this data class - POINT, LINE or POLYGON |
| SHAPE_PROJECTION | varchar2(10) | Projection system for spatial coordinates. Must be WGS84 | |
| SHAPE_MEASURES | varchar2(1) | default 'N' not null check (SHAPE_MEASURES in ('Y','N')) | Coordinates have measure values. Y or N |
| SPATIAL_TABLE | varchar2(61) | Name of spatial table (SCHEMA.TABLENAME) for shapes (if applicable) | |
| SPATIAL_GEOMETRY | varchar2(30) | Name of column in spatial table which stores coordinate info | |
| SPATIAL_FORMAT | varchar2(10) | Format in which to load data into spatial table. Must be SDO or null. | |
| SPATIAL_KEY | varchar2(30) | Name of integer key field in spatial table used to link to attribute table | |
| SPATIAL_KEY_SEQUENCE | varchar2(61) | Name of Oracle sequence (SCHEMA.SEQUENCENAME) used to generate unique values for SDE-required unique integer key on spatial table. If no sequence is specified then the table is queried to retrieve the current maximum value for this column, and this value is incremented to create a new value | |
| SPATIAL_NAME | varchar2(30) | Name of column in spatial table which stores the object name | |
| ATTRIBUTE_TABLE | varchar2(61) | Name of business table (SCHEMA.TABLENAME) for shapes (if applicable) | |
| ATTRIBUTE_X | varchar2(30) | Name of column in attribute table which stores X/Longitude coordinate of POINT shape. If the shape type is a single POINT, then the coordinate value may be stored in the attribute table, with a trigger set up to synchronise the spatial table. If this field has a value, then the SPATIAL_TABLE and SPATIAL_GEOMETRY columns must be null | |
| ATTRIBUTE_Y | varchar2(30) | Name of column in attribute table which stores Y/Latitude coordinate of POINT shape. If the shape type is a single POINT, then the coordinate value may be stored in the attribute table, with a trigger set up to synchronise the spatial table. If this field has a value, then the SPATIAL_TABLE and SPATIAL_GEOMETRY columns must be null | |
| ATTRIBUTE_NAME | varchar2(30) | Name of column in attribute table which stores the object name | |
| ATTRIBUTE_KEY | varchar2(30) | Name of primary key field in attribute table | |
| ATTRIBUTE_KEY_SEQUENCE | varchar2(61) | Name of Oralce Sequence (SCHEMA.SEQUENCENAME) used to generate unique values for attribute table primary key field | |
| ATTRIBUTE_FIELD_MAPPINGS | varchar2(4000) | Not yet implemented |
CDF Templates are predefined catalogue descriptions. A template can be used within Dougal to create a customised CDF, or can be used directly with Florence or Zebedee to create a catalogue.
Templates can be saved as either User Templates or System
Templates.
User Templates are stored in the TEMPLATE subdirectory of
your network user or local directory (see
LEA System Installation - System, Data and
User Directories).
System Templates are stored in the TEMPLATE
subdirectory of the LYNXSYS directory, and are accessible to all users
on all LEA-enabled PCs.
Each Template has a unique GUID generated by Windows. CDF Templates should only be created with the Dougal - Save As Template option. Templates can be manually moved from your user TEMPLATE directory to the system TEMPLATE directory to enable a template for all users.
The CDF Template Selection dialogue is used in Dougal, Florence and Zebedee. The tabs at the top of list categorise CDF templates by their Layer Type (see above). A popup menu allows the list to be viewed as large or small icons, and in list or report mode, and the description of the template is displayed in a hint when the muse hovers over a template icon.
A CDF can define field constraints which are independent of the constraints defined by the underlying database table, and are evaluated before the record is checked by the database. CDF constraints specify
A CDF can also define record-level constraints (implemented for Oracle database tables only) which can check the value of one field compared to the value of another field in the same record or set of records from another table (similar to a table lookup, but without the drop-down list). Record-level constraints are defined using SQL syntax, and are evaluated before the record is posted to the database.
Constraint violation errors can occur when adding new records or editing
existing records.
Error messages may be displayed giving you various options
to respond to constraint violations.
If the application is adding records in
batch-mode (eg Florence) and constraint
checking is turned on, then you will have options to
If the application is adding records one at a time (eg Dylan), you will have options to
A Catalogue Description File is an ASCII file that starts with the reserved string [lynx] in common with all LEA INI and parameter files. The program and version keys in this section are used by applications reading the CDF to check the format of the file.
In the [table type] section, the LEA objects key lists the LEA Object INI files used in this catalogue description as a comma-delimited string prefixed by an asterisk character to preserve quotes which can get stripped from strings when reading and writing INI files - eg::
LEA objects=*LEAOBJ.INI,BASEOBJ.INI
The description key gives a short text description of the CDF, which is displayed in LEA applications.
The database table structure is defined in the [layout] section of the file. The field count key is the number of fields defined in the catalogue definition. Each field of the table is then described as a separate key as a comma-delimited list of values. The format of the description is:
FieldNo=ININame,AttrNo,FieldName,FieldDescription[,FieldType,FieldLength]
where:
The [index] section describes the indexing of the catalogue. The primary key count key lists the number of fields that should be used to create the primary key; for example, primary key count=3 indicates that the first 3 fields should be used to generate the primary key. The combined values of all fields within the primary key for each record must be unique.
The [edit mask] section lists the edit mask for each field in the form:
FieldNo=*EditMask
where:
If there is no entry for a field number, then the field has no edit mask.
The [validity] section describes the constraints imposed on values for each field. Validity checks for each field are described as a separate key as a comma-delimited list of values. The format of the description is:
For STRING fields
FieldNo=AllowBlank,HasMin,HasMax,HasDefault,AutoInc,MinValue,MaxValue,DefaultValue[,LookupMethod[,LookupDatabase,LookupTable, LookupField[,CustomSort[,FilterField,ValueField]]]]
if LookupMethod=1 (static lookup list) then another key,value entry is included in the section:
FieldNo LOOKUP LIST=*lookuplistvalues
if LookupMethod=4 (filtered lookup list} then another key,value entry is included in the section for each value to match:
FieldNo FILTERED LOOKUP MatchVal=*lookuplistvalues
if LookupMethod=4 then the following lookuplist will be used when no value is matched
FieldNo DEFAULT FILTERED LOOKUP=*lookuplistvalues
if CustomSort=1 (true) then another key,value entry is included in the section
FieldNo LOOKUP SORT=*customsortstring
For INTEGER fields
FieldNo=AllowBlank,HasMin,HasMax,HasDefault,AutoInc,MinValue,MaxValue,DefaultValue[,UseSeq[,SeqDB,SeqName]]
For other field types
FieldNo=AllowBlank,HasMin,HasMax,HasDefault,AutoInc,MinValue,MaxValue,DefaultValue
where:
Custom fields may also have an additional key:
FieldNo INITIALLY BLANK=1
which specifies that although the field is defined as auto-increment, or using a Oracle sequence, or with a default value, the value of the field for new records should initially be null. LEA applications provide a mechanism to get the default/increment value on demand.
If there is no entry for a field number, then the field has no validity checks
The [constraints] section lists any record-level constraints defined for the CDF. The constraint count key is the number of record constraints defined in the catalogue definition. Each constraint is then listed as a separate numbered key. The format of this key is:
ConstraintNo=ConstraintText
where:
This section can also contain an additional key for each constraint:
ConstraintNo ERROR MESSAGE=ConstraintErrorMessage
where:
If the error message key is not present for a constraint, then the default error message will be displayed.
Listed below are the error messages that may be generated by applications that use CDFs
The file that is specified is not a catalogue description file. CDF files contain only ASCII characters and the first line is always [lynx]. The specified file may belong to a non-Lynx application, or may have become badly corrupted.
The database table definition of the specified catalogue does not match the one defined in the catalogue definition file.Either the number of fields is different, or the field types do not match. The application cannot interpret a catalogue table without the accompanying CDF. Make sure that you select the correct CDF for the catalogue table file you wish to open.
You have attempted to open a catalogue table file without specifying a CDF. The application cannot interpret a catalogue table without the accompanying CDF.
These errors mean that the CDF file is incompatible with the application that is attempting to read it. The CDF file's version number mismatches the allowed version range string in the CDFLIB.INI file. You are probably trying to use a CDF file created by an earlier (or later) version of an application, whose internal structure does not match that expected by the current application.When the parameter file's version number is missing, the file is probably seriously corrupted.
Both these errors could mean that you may have a number of conflicting versions of program INI files installed on your system.
The primary index fields read from the CDF are incompatible with the field definitions read from the same file. This probably means that the CDF has become corrupted.
See also: