Field properties
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:
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.
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.
• | Linked fields retrieve their data from another database. |
• | The information in an enumerative field can either come from a static list that you define beforehand, or a local field. |
• | A normal field is a field that is not a linked field nor an enumerative field. A link reference tag is also a normal field. |
• | Automatically numbered fields retrieve their data from an automatic routine set up on the Automatic numbering tab. Linked fields can be automatically numbered as well as normal fields, but then the linked-to field itself cannot be an automatically numbered field as well. Also any other linked fields in other database definitions which link to the same field cannot be automatically numbered too. |
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.
• | The extra tabs for a linked field are: Linked field properties, Relation fields, Link screens and Linked field mapping. |
• | The extra tab for an enumerative field is: Enumeration values. |
• | The extra tab for an automatic numbering field is: Automatic numbering. |
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:
• | The first character of the name must be a letter (a-z or A-Z). Disallowed initial characters for names include digits, diacritics, the full stop and characters like %&!*+/{}()[]<>-. |
• | Names should not begin with "XML" or "xml". |
• | Beyond the first character, characters permitted in names are letters, digits, hyphens, underscores and the full stop. Not allowed are characters which either are or reasonably could be used as delimiters, like the colon, the semi-colon, a comma, parentheses or brackets for example. |
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.
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.
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.
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:
Data type |
Meaning |
|||||||
Application |
If you give a field this data type, you can upload a file or enter a file name in this entry field in the application, including its path. This path is then shown underlined to indicate that the field is a linked field. When the user clicks the underlined link, the file will be downloaded to their local Downloads folder. As soon as you choose this data type for a normal field, the extra tab Application field properties is added to the properties tabs to further set up this specific type of field. |
|||||||
Date (general) |
This date field will accept a date in five possible formats. The following notations are allowed: |
|||||||
(EUR) dd/mm/yy |
(e.g. 31/12/94) |
|||||||
(EUR) dd/mm/yyyy |
(e.g. 31/12/1994) |
|||||||
(ISO) yy-mm-dd |
(e.g. 94-12-31) |
|||||||
(ISO) yyyy-mm-dd |
(e.g. 1994-12-31) |
|||||||
(Julian) yyyy-ddd |
(e.g. 1994-365) |
|||||||
The European date format dd-mm-yyyy is accepted as well, but is now deprecated. |
||||||||
DateISO (yyyy-mm-dd) |
Can only contain dates like 2002-01-31 or partial dates like 2003-12 or 2001. |
|||||||
DatePeriod |
A field of this type (only implemented for CALM, not for Collections) is a plain text field where you enter a natural language date (for example "Early 19th Century") which is then parsed to a date range. |
|||||||
DateUSA (mm/dd/yyyy) |
Can only contain dates like 01/31/2002. |
|||||||
Enumeration |
Making a field enumerative means in the application the entry field has a drop-down list out of which the user has to pick an option. If you set this field to Enumeration, you must also fill in the Enumeration values tab. |
|||||||
European date (dd/mm/yyyy) |
Can only contain dates like 31/01/2002. |
|||||||
Geo location |
In Axiell Collections, a field with this data type (available from Designer 7.3) will show an extra Geographical map tab in the Find data for the field window (if the geolocation field is a linked field) allowing for an easier validation of geographical names by means of an actual map. A geolocation field will also appear in the Geographical map view as one of the fields which the user may select to mark the places stored in that field on the geographical map. The intention is not to create any new fields with this data type but to change the data type of one or more existing fields (linked or not) that contain geographical names, (mostly from data type Text) to Geo location if you'd like those fields to have the validation by geographical map (if it concerns a linked field) and if you want those fields to be selectable in the Geographical map view of Axiell Collections. An example would be the production.place field in the collect.inf database structure. If you make it a geolocation field by changing its field definition (no other settings required), then the Geographical map view in Axiell Collections allows the user to show the production places of a selection of records as coloured markers on a geographical map which can be zoomed in or out and scrolled in all directions. See the relevant Help topic for more information. |
|||||||
Geo-json |
Create a geojson field to allow users to register locations and areas by means of their location on a geographical map and also to search for records by a variety of map manipulations to select places, precise spots or areas of different shapes. Geojson fields are part of what's known as GIS (Geographic Information System) functionality. This functionality requires SQL Server 2017 or higher. In the Collections user interface, a geojson field has a peculiar appearance: it may have a field label but no entry field, just a map icon. The icon is empty if the field contains no data, while it has a location pointer when the field is filled. The user will never see the actual (GeoJSON formatted data) that is stored in the field, only the icon will appear. Clicking the empty icon when the record is in edit mode will allow the user to select a new location on a map (which opens in a separate window) whilst clicking the icon with the location pointer in either display or edit mode will show the earlier selected or stored location on the map. Emptying a filled-in geojson field can be done by clicking the Clear button in the map display. |
|||||||
Group |
<redundant option> |
|||||||
Html |
An HTML field is meant for long, laid-out text. Layout can be applied to the text during editing of the record. |
|||||||
Image |
When this field is to contain paths to image files, you must assign the Image type to it. The reason is that when you print this field through an adapl or Word template, Collections must know whether it should print the path or the image to which the path points: when printing a field of this type, the image will be printed and not the path. (For displaying paths and images in a running Collections application this type setting is not relevant: the Media Viewer will automatically display all linked images in the record, and an entry field will display the path.) As soon as you choose this data type for a normal field, the extra tab Image properties is added to the properties tabs to further set up this specific type of field. |
|||||||
Integer |
Will accept only whole numbers. The numeric value may be preceded by a plus or minus sign. |
|||||||
Isbn |
Can contain a valid ISBN, either with or without punctuation (e.g. 90-03-90201-1 or 978-90-03-90201-6). |
|||||||
Issn |
Can contain a valid ISSN, either with or without punctuation (e.g. 0040-9170). |
|||||||
Letters (A-Z/a-z) only |
Will only accept alphabetic characters and spaces. |
|||||||
Logical (Boolean) |
A logical field is a field which is one position long. If the field contains any character, its contents are considered 'true'. If it does not contain a character, the field contents are considered 'false'. |
|||||||
Numeric (floating point) |
Will only accept numeric characters. Uses a full-stop (a dot) as the decimal symbol for the stored value (although entry and presentation of the number may differ). The numeric value may be preceded by a plus or minus sign. |
|||||||
Password |
A field of data type Password is a field in which every typed character in Axiell Collections will be replaced (hidden) by a dot, so that no one can see the text (typically a password in a user details database) being typed. When saving the record, the typed password will be saved encrypted as a much larger text which is displayed as dots too in both edit and display mode. When you export or print this field, the encrypted text itself will be exported. |
|||||||
Period |
Designer 7.9 and Collections 1.15 introduced the Period field type and accompanying Period index type which allows users to enter and save date periods expressed in natural language, like "12th century", "Spring 2022", "late 2018", "Early 19th Century - 2022", "1950s" etc., in a record while the indexed values actually become date ranges in the form of real (numerical forms of) ISO start and end dates, like 1100.0101 - 1199.1231, 2022.0301 - 2022.0531, 2018.0901 - 2018.1231, 1800.0101 - 2022.1231 and 1950.0101 - 1959.1231 respectively. See the full implementation topic for more information. |
|||||||
Rtf (rich text) |
This field data type is deprecated and should not be used in Collections. We recommend you use the HTML field data type instead. Existing, filled-in Rtf fields cannot be converted to HTML fields though. |
|||||||
Temporary |
Use this type for fields in which you want to store values temporarily (for instance for displaying or printing temporarily compounded field values). Fields of this type always have full rights, which means they can be written to, while the database may only have read rights. Therefore these fields will not be stored in the database and will also not appear in field lists in Collections applications. |
|||||||
Text |
Will accept all characters. |
|||||||
Time (hh:mm:ss) |
This field will accept a time. The only accepted notation in Collections until 1.10.2 was hh:mm:ss. From Collections 1.11 though, hh:mm is accepted too, although when a time is entered into a time field manually using the hh:mm format, it receives a seconds value of :00 automatically. The minimal value of the field is 00:00:00 while the maximum value is 23:59:59 |
|||||||
URI |
A URI field may contain a manually or automatically entered URI identifying the current record. When it has been set up to fill automatically, that is done on storage of the record if it concerns a new record only, even if the user has manually entered a value (then it will be overwritten). In existing records, URI fields that initially were filled automatically can be edited manually though.
A field definition of the URI data type gets a URI field properties tab where you can enter the relevant properties. This implementation of URI fields is associated with the concept of Linked Open Data. Click here for more information about the implementation of Linked Open Data in Collections model applications 5.0 and up. |
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:
• | ISO date (yyyy-mm-dd): the date format is presented unchanged, this is the default case for existing ISO date fields. |
• | European date (dd/mm/yyyy): this ISO date field will be presented in the format commonly used in Europe. |
• | American date (mm/dd/yyyy): this ISO date field will be presented in the format commonly used in America. |
• | Locale date (short): this makes the presentation of this ISO date field variable, by linking it to the local Windows language. For example, if this language is English then Collections will automatically present this date field in the European format. |
• | Locale date (long): this presentation too is variable and linked to the local Windows language. However, the presentation is a date half written in words. For English that could be something like Tuesday 2 December 2003, for example. |
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.
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.
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.
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.
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.
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.
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.
(Note that there are two ways of implementing multilingual fields; click here for more information.)
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.
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.
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:
• | In Collections 1.7.3 and earlier, field contents in write-once fields, entered manually, filled by copying the record, filled by default value or by an adapl, won't be editable anymore from the moment the cursor is no longer in the screen field or when the field was filled but never edited by the user manually. From Collections 1.7.4 though, the field remains editable as long as the record hasn't been saved. This allows users to still change an incorrectly entered or default or copied value in a write-once field before saving the record. |
• | New occurrences of write-once fields or field groups can still be added. |
• | Deletion of write-once field occurrences that have saved data in them is not possible. When a write-once field is part of a field group (maybe also containing normal fields), then a field group occurrence can only be deleted if the write-once field doesn't have saved data in it. So, earlier saved empty field group occurrences containing one or more write-once fields can always be removed. If the user clicks the Remove row icon for a field occurrence that can't be deleted, a notification message will inform the user of the reason why. |
• | The copy record function copies the management details as well, but as you are creating a new record, its storage adapl will try to fill the Input fields on the Management details tab with new data. From Collections 1.7.4, that's no problem because from that version, data in write-once fields can be edited as long as it hasn't been saved in that record yet. In Collections 1.7.3 and earlier though, saving a copied record won't be possible if you've set the write-once option for those fields. To prevent those circumstances from arising, make sure you also deselect the Exchangeable option for the Input fields in the data dictionary: that way they won't be copied along and the storage adapl will be able to fill them with new data. |