Field properties per dataset
Contents
From Axiell Designer 7.3.15038.1, functionality is available allowing you to override some specific properties of fields per dataset of a database, giving you the possibility to specify a different field name per dataset for one and the same field tag, or to specify different access rights for the field per dataset, a different link domain, (internal) link scope, help key or different enumeration values, for example. This functionality follows from a requirement for compliancy with the CEN 15907 metadata standard (as used by film archives) and the FRBR (Functional Requirements for Bibliographic Records) standard.
In Collections, fields have always been specified for a specific database table as a whole. For example: in the 5.1 collect.inf database table definition, which contains all dataset, index and field definitions for museum, archive and library object records, you can find the field definition for object_number (tag IN), amongst others. Its field name and other properties would always apply to all datasets within that database table (recall that datasets are actually just partial record number ranges of the database table, created to separate similar records by record type or branch). With the implementation of this functionality this is still the case, but if you want you can now "include" one of the existing data dictionary fields in one or more dataset specifications within the database table definition and override some properties with a different value which will then only apply when the field is accessed from within that particular dataset in a live Collections application, while the original, master field properties will still apply to any other datasets in which the field has not been included or in which the field has been included indeed but has not received any new settings. The moment you actually include an existing field in a dataset, a copy of the original field definition is placed underneath the Fields node underneath the selected dataset node in the current database table definition, where you can change the available "overloadable" properties as you wish. Note that greyed out properties can never be overridden and autonumbering fields always have a database-wide counter and will share properties across datasets.
To include an existing field in a dataset, do the following:
| 1. | Right-click the desired dataset of a database table in the Application browser tree view and select Include field in the pop-up menu. |
| 2. | Now select an existing field from the data dictionary of the current database table. Note that on dataset level you cannot create new fields: you must always "include" an existing field.  |
| 3. | A copy of the field has now been included in the relevant dataset. Select the field underneath the dataset to change any of the available properties. The new properties will only be valid in this dataset, they won't be copied to the database table definition of the field nor to other copies of the field. Even though the dataset level field definition starts of as a copy and the field tag must remain the same, it'll live its own life from now on. Changes to the field on database level won't affect any copies in datasets. The exception to the rule maybe, is when you delete a field definition: when you do that on dataset level, the original database table level version will remain as is, while if you delete a field definition on database table level then that will be removed along with any of its derived field definitions in the datasets. In the screenshot below you can see how the IN tag (the object_number field) has been included in the archivecatalogue dataset of collect and how its field name and translations have been changed afterwards.  With this particular change you could now use the reference_code field to (advanced) search the Archives (catalogue) dataset in your live Collections application, instead of the object_number field. Other changes to the properties of included fields on dataset level may have a deeper impact or may instead be hardly noticeable to the user. |
In the database table tree view underneath Fields and in the database Field list view in the Application browser of Axiell Designer 7.4 and higher, fields of which the properties are overridden in at least one dataset are marked with a different colour (call it yellow, ochre, olive or gold) so you'll recognize them at once and know that you should first look up the relevant field definition underneath the relevant dataset since its properties have priority over the field properties on database table level.
