On the Field properties tab, which is present when you have selected a new or existing data dictionary field in a database, you determine the general properties of this field.
Click here for information on how to edit properties in general. And click here to read about how to manage objects in the tree view in the Application browser. On the current tab you'll find the following settings:

Field Tag

Here, you enter the tag of the field which properties you want to specify. The tag consists of a maximum of two characters, of which the first may be a letter, a digit or a % sign, and the second a letter or a digit. Collections distinguishes between upper and lower case letters. ‘%0’ is always reserved (for the record number). Tags must be unique in the current database definition (.inf): Axiell Designer will check the tag you entered and warns you if it already appears in the data dictionary of the current database definition, forcing you to enter a different tag.

Type

A field can be any of three basic types: Normal field, Linked field or Enumerative field. You can set normal and linked fields to be automatically numbered as well, by marking the Automatic numbering field checkbox.

Note that a field cannot be linked and be enumerative at the same time.
Also, an existing field of a certain type, which already contains data, cannot just be converted to another type by marking a different checkbox: this is because the different field types store data in their own way. To convert a field from one type to another can be a complex process in which existing data has to be exported and imported and/or converted by a custom adapl, and you'll also have to create a whole new field definition to replace the old one. However, there is a way to display a linked field as a drop-down list. The way data is stored in such a field is no different from a "normal" linked field, it just displays all possible values from the linked database in a drop-down list: only create such a field if there's only a very limited number of possible values for the field, otherwise the drop-down list gets too long. All it takes to have a linked field displayed as a drop-down list is to mark the Do not show link screen option. (Note that this is not the same as an enumerative field!)

As soon as you choose the type of this field, extra tabs may be added to the properties tabs to further set up this specific type of field.

Field names

For each language in which your application must be presentable, you must provide a field name here. You can use this name instead of the tag in searches using the advanced search language in a running application, and you need field names for export jobs, for the WebAPI configuration, for the creation of XSLT stylesheets and more. For example, you could use the field name author instead of the more cryptic tag au. In the past, the field name could be maximally 32 characters long, but that limit no longer applies, so longer field names are possible. Field names may not contain any spaces. Further restrictions to field names apply because (English) field names are also used as XML element names in XML output produced by the WebAPI or the export function of Collections. For XML tag names, and thus for field names, the following practical guidelines can be given:

Note that this list is not complete, but English field names usually have no need for exotic characters.

One existing conflicting field in many Collections applications is the temporary [display_only] field in collect.inf. The brackets in its name may prove problematic when processed as an XML tag name by an XML parser. However, because it is a temporary field, filled by a before-screen adapl, it is very unlikely to cause problems because it won't be included in records retrieved via the WebAPI. If the field still causes a problem anyway, you can change the English field name into something without brackets: display_only for example. The only other place where the original field name might be in use is in Word templates; so then check your Word templates for the appearance of [display_only], and change it to the new field name.

Maximum length

The maximum length that data in the field may have. You can enter a value between 0 and 255. If you enter 0, Collections will enable word-wrapping for the field and in the running application the field will automatically extend vertically to show the entire content. In other words, when text is entered in the field, Collections will automatically move a word to the next line if it no longer fits on the current line. This makes it possible for a field to contain far more than 255 characters.

In the Screen editor, you can only visually specify the length of a screen entry field (a text box) and Collections also resizes fields depending on the width of the Record details view so you cannot set the length of a screen field to match the data dictionary field length. However, in entry fields that are shorter than the data dictionary field length, you can scroll the contents left and right.

Repeatable

Mark this checkbox if you want this field to be able to have more than one occurrence (occurrences are numbered instances/repetitions of the same field). For example, because a book may have more than one author, the author field must be repeatable so you can enter each author in its own occurrence of this field.
To be able to actually add new occurrences of an entry field on a screen in a running application, the Repeatable property for that entry field must be set to Repeated or RepeatedUnique.
If the screen field is set to NotRepeated while the data dictionary field is Repeatable, the screen only displays the first occurrence of the data dictionary field, but the data dictionary field may hold more occurrences (e.g. from an import). The other way around, when a data dictionary field is set to non-repeatable, while the screen field is repeatable, the data dictionary definition takes precedence: then the screen entry field cannot have more than one occurrence.

Data type

Here you can choose from a list of possible data types to specify the type of data that can be entered and saved in this field. The following types may be selected:

Presentation format

The contents of fields of data type ISO date or Numeric may be presented on screen differently from the way that the content has been stored, to allow for automatic language or region-specific format presentation. From Collections 1.8 and Designer 7.7.1 this also applies to Integer fields.
Note that if you assign fields of data type ISO date a different presentation format, then data entry requirements are determined by the presentation format. This means that with, for example, the European date presentation format you will always have to enter a full European date, even though the ISO date format in which the date will really be stored could allow partial dates. So if you need to be able to register partial dates too, the default ISO date presentation format might be the better choice.

- ISO date presentation

In Collections databases, dates can occur in different formats, for instance as European date (dd/mm/yyyy), American date (mm/dd/yyyy) or ISO date (yyyy-mm-dd). This is not beneficial to the international exchangeability of data which contains such dates. That is why in new Collections applications, date fields in the data dictionary are set to the ISO date format more and more. To still be able to present dates on screens in the locally used format, it is possible to set a fixed or variable presentation type for ISO date fields in the data dictionary, using the current property. You have a choice between the following presentation types:

The storage of an ISO date field will always be in ISO format, regardless of the presentation you choose for the field.
Entry of an ISO date is normally done through a small calendar, from which you pick a day. However, after your choice, the date will be presented in the selected presentation format.
Note that the Locale date (long) format needs more space on the screen. So for this presentation you'll have to lengthen the relevant date field on all applicable screens, before you'll be able to properly observe the new presentation in a running application.
Searching on date fields in the Search wizard and in search forms, is self-explanatory. In the Expert search system you can search in differently presented ISO date fields in two ways, namely on ISO date and on the date in the presentation format. So, an ISO date field which has the European format as presentation format, can be searched equally well with ISO dates as with European dates. An exception to this rule is the ISO date with the Locale date (long) presentation format: these fields can be searched on ISO dates and on Locale date (short) dates. So you can't search these fields on, for example, "Wednesday 15 April 1970".
Printing to a Word template uses the presentation format (if set), while printing with an adapl uses the stored format.

- Numerical value presentation

In Axiell Collections, the presentation format of numerical fields only depends on the current interface language in Collections. The Numerical value presentation option is irrelevant for Collections and Collections will ignore it.

Collections uses the currently selected interface language of the current user to derive the locales. Thus, all numeric formats are presented in a format that is natural to the user’s UI locale. In the case of Dutch (NL) this will be using commas for the decimal separators and periods as thousands separators (although thousands separators cannot be entered by the user and are not stored, but are present during display only). This only concerns the presentation format though: Collections records are always stored in the database with a dot as the decimal separator.
So in Collections, the presentation format depends on the selected interface language, but the printed separator depends on the method of printing too: printing to a Word template uses the interface language based separator while printing via an adapl uses the dot as separator.
Exporting from Collections uses the dot.

- Integer

By default, with this option set to No formatting, from Collections 1.8, integer fields will be presented without dots or comma's as thousand separators. (Prior to that version, integer fields would be presented with dots or comma's as thousand separators by default, but for some values, like years, this was not desirable.)
If the dot/comma presentation of integers is still required for a field, it must now be set via the Use selected language setting for the Presentation format option. The selected language refers to the local Windows settings.

Member of group

If you want a data dictionary field to be part of a group of fields in the data dictionary, you should give all these fields the same group name. A group of fields is used to repeat or move together when you add or delete a group occurrence for one of these fields in a running application.
For Axiell Collections (and ADAPL and the WebAPI), you should always define a group name here, on data dictionary level in the database setup: the now obsolete possibility to specify a group number on screen level in the application setup should not be used anymore.

Further note that ADAPL data dictionary field group functionality like adding or sorting group occurrences, with the exception of REPCNT, is switched off during import of data. Any adapls used for importing should take this into account when manipulating data.

Exchangeable

With this option you determine whether the contents of this field will be copied to a new record when you copy an entire record in Collections or when you derive a record with this field. Mark this checkbox to allow copying of the field.

Note that in the past, when the Exchangeable option didn't exist yet, an adapl (a copy record procedure) could have been used to prevent specific fields from being copied, when copying an entire record.

Occurrence sort order

With this option you determine whether the occurrences of this field will be sorted or not, before the record is saved. From Collections 1.19.1.14285, sorting will only actually be executed when the field contents have changed, which gives a huge performance boost when a record is saved (e.g. after editing it manually or during a Change location procedure), when you have many fields with sorted occurrences.
You can choose between Do not sort e.g. (z, a, c) or (2, 5, 1), Sort ascending (a, c, z) or (1, 2, 5), or Sort descending (z, c, a) or (5, 2, 1). The type of the sorting (alphabetical, numerical or by date) depends on the data type of the current field; alpha-numerical sorting of occurrences, as would be handy for text fields which also contain numbers, is not possible.
Setting this option for an enumerative field means that the occurrences will be sorted alphabetically on the neutral values, not on their translations.
If this field occurs in a data dictionary group (you can sort on a merged-in field too), then that group stays together after sorting, as is desirable. Never set this option for groups defined on screen level only, as it will corrupt your data. So always define field groups on data dictionary level.
If a sort is applied to more than one field in a (data dictionary) group (which is not permitted), then the sorting order is determined by the last sort field in that group.

In the properties of an internal link definition you may also set the Sort tags for occurrences of fields. This may result in conflicting sort instructions if you set both sort options differently for internally linked fields. But Collections simply first executes any sorting set up in the internal link definition and after that, any sorting set up in the field properties.

Multilingual

If you make a field multilingual by marking this option, then the Collections user can enter a value for this field (and each occurrence of it) in any language that you have set in the Data languages list for the .pbk file of this application. In Collections, the user must choose the language in which he or she wishes to enter data in this field, from the Data language button submenu (this menu only offers the languages set in the Data languages list in the .pbk).

If you want to create multilingual fields, it's best if those fields do not contain any data yet. This is because when a field which already contains data is made multilingual, the data in the field will not get a language attribute automatically. If the field already contains data, a data conversion is required. Use either the AddDataLanguage tool or the RemoveLanguageFromData tool for the relevant data conversion: see the Database integrity tools manual for more information about that.

Typically you make a careful selection of fields which you'd like to be multilingual because only in those fields people need to be able to enter a value in different languages. Linked fields need extra consideration: a proper application setup requires that for linked fields (not their link reference fields), merge destination fields and write-back destination fields the Multilingual field setting complies with their merge/write back source fields. In other words, if a linked field is multilingual, then its source field in the linked database table must be multilingual too and this applies to all other source and destination fields on the Linked field mapping tab of a linked field as well (if one is multilingual then its counterpart must be multilingual too). Link reference fields must never be multilingual because they only contain a record number. The other way around is even more noteworthy: if a "core" field like the term field in thesau.inf or the name field in people.inf is made multilingual, then all fields in other database tables linking to this field must be made multilingual too. That looks like a lot of work if you're starting out making an application multilingual, but Designer can help. At first, only make the mentioned "core" (non-linked) fields multilingual by marking the current option. Now save the edited .inf files, close Designer and reopen it. Designer will now recognize that fields linking to the "core" fields (and any destination merge and write-back fields) are not multilingual yet and will correct that for you by automatically marking the Multilingual setting for those fields!  Designer will report all modifications in the main window. If you agree with all modifications, then save all .inf’s manually again because Designer hasn’t done that yet. The automatic adjustments by Designer might trigger that still some other fields need to be set to multilingual (for example in the case of two-level merging). Therefore, always close and reopen Designer again, to see if Designer wants to make more adjustments. If so, check them, save the .inf's again and repeat the closing and reopening until Designer doesn't want to make any changes any more. That's the bulk of the work already done!

In the XML format in which every record is stored in the SQL database, every translation of a value in a field occurrence is saved in its own XML tag specific for the relevant language: this tag is the code for the language as shown in the Name column in the Data languages list in the application properties.

As mentioned, link reference tags must never be multilingual, even if they are associated with a multilingual linked field.
Enumerative fields should never be multilingual either, because of the nature of the field. However, in Designer 7.7.2 and older versions you could still accidentally mark the current Multilingual checkbox in the properties of an enumerative field, causing incorrect record XML (with a lang attribute for the enumerative field). Designer 7.7.3 (release version) and higher will disable the Multilingual checkbox for enumerative fields (this disabling depends on the Enumeration data type of the field) so that this error can't be made in the future. In the meantime, for fields that already have this erroneous setup, Collections 1.11 will no longer stumble on the incorrect XML and on saving a record with such improper XML it will automatically remove the inappropriate lang attribute, slowly cleaning up the faulty XML this way.

After making a field multilingual, you must reindex the index on the field (only if it already has an index). If the field is a long text field you must reindex all word indexes, to rebuild the wordlist table as well.

(Read more about multilingual fields here.)

Do not show in lists

Apart from fields of the Temporary data type, all fields which have been defined in the data dictionary will be shown in field lists such as those on the Advanced search tab in Collections.
Still, it may be that you wish that certain fields (of other data types) wouldn’t be in those lists because users shouldn't use them for searching, for example. Then simply mark the Do not show in lists option to keep the currently edited data dictionary field from the field lists in your Collections application.

Inheritable

In Axiell Collections, the Inheritable option (available from Designer 7.3.15216.1) allows you to automatically display and possibly copy data from this exact field from the first record higher in the hierarchy in which this field has actually been filled in.
An example might clarify things: suppose you have an object record for a "dollhouse" which has Parts (child records) describing the contents of the dollhouse. And maybe some of those parts, like a "closet (miniature)", may even have Parts of their own. If you are registering such hierarchies regularly and you find you often need to copy the contents of some field from the top record of the hierarchy to its child records (or to just be able to see its contents) - e.g. a description that applies to all parts, like condition notes about the dollhouse and its parts or some other notes relevant to all children - then a mechanism for copying that content might come in handy. And that is just what the Inheritable option is for. Once you set it for a field, say the (Condition) Notes field in the collect database, every time you view or edit an object record, Collections will automatically look upwards in the hierarchy (if present) to see if the parent record has data in that Notes field. If not, Collections will check the grandparent (if present) and so on, until a record with a filled (Condition) Notes field has been found. If so, Collections will display that content greyed out in the (Condition) Notes field of the current record, if the field was still empty. Even though the copied content is displayed in the record, it is not yet part of the current record. To save the copied contents, the user would have to put the record in edit mode and simply click the relevant field (the Notes field in our example) or put the cursor in the field and start typing new text and/or delete copied text to fully activate the field contents (the text colour changes to normal). Now saving the record includes the activated field contents: a quick way to (partially or completely) copy data from other records! Remember that typing new text in such fields is possible as well, so you're not stuck with the copied text.

You can set this option for as many fields as you like, and they can be of any data type including for linked fields. For both linked and non-linked field related grouped fields you can only set this option for all fields in the group (because of data integrity reasons): Designer does that for you once you set the option for one of the fields in the group*.
Per field, the user can always choose whether to activate (to store) the copied contents or not. If the user doesn't want to duplicate data from the higher records at all, he'll probably never activate the data and will just enjoy the fact that data from parent records is conveniently visible in the edited record. And searching on such never activated inherited data is possible too, using the expand operator.
Do observe that inherited data may come from different elders: one field might display data from the direct parent record, while for another field the direct parent doesn't have any information while its grandparent does.

Which fields make up the parent-child relations, has been specified in the internal link definition of type Hierarchical in your database structure definition (.inf file).

In the Application browser there's also a quick way to find fields which have been made inheritable or are part of an inheritable field group: in the tree view in the left window pane, click the Fields node underneath the desired database definition to display the complete Field list in the window pane on the right. Scroll to the right to find the inheritable column. Fields which have been made inheritable are marked yes in this column.

* For data integrity reasons it is required that once you set a data dictionary field to Inheritable, the same setting should be made for all fields in the same field group. From Designer 7.7.2, to enforce that requirement and to help you do it right, you are prompted when you mark or deselect the checkbox.

The confirmation question reads the same in both cases: if you mark the checkbox and you answer Yes, all relevant fields in the current field group will be set to Inheritable as well (excluding the mentioned linked fields), while if you deselect the checkbox, answering Yes means that the Inheritable setting will be removed from all fields in the current field group.
Answering No will cancel your action, so if you just marked the checkbox, No will remove the check again (and vice versa for if you just deselected the checkbox).

If inheritance for a linked field group was set up before Designer enforced the setting for the whole group, you may find that only the link reference field of that group was set to inheritable, but that shouldn't be a problem.

Write-once

For security reasons you might like some fields, like the Input and Edit fields on the Management details tab for example, to be writable only once, to automatically become non-editable after saving the record. As it happens, the Input and Edit field contents (except for the Notes field contents in those field groups) cannot be edited in the fields themselves (they are read-only on the screen) because they are filled by the storage adapl when the record is saved. Nonetheless, the contents of these fields can be changed via the Search and replace functionality since this functionality has no regard for screen definitions and only looks at the data dictionary. To protect earlier saved field contents from any later changes, whether through record editing, search and replace or adapl functionality, you can set a Write once option for such fields in the data dictionary. Simply look up the desired fields in the relevant database structure definition and mark the Write once checkbox. The best practice is probably to set this option only for automatically filled fields which are read-only on the screen anyway, because all saved data in these fields won't be editable in Axiell Collections again.

When a user tries to edit and save a write-once field anyway, a notification message similar to the following will appear and the record can't be saved:

Important notes: