Friendly database properties
On the Friendly database properties tab, which is present when you have selected a new or existing friendly database for a data source in an application in the Application browser, you refer to compatible databases for the current data source.
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:
Specify the title of this compatible database in as many languages as you want to make available to users. Consider including information about whether the original record will be kept or will be deleted after deriving.
The titles of one or more friendly databases specified for the current data source, will be shown in the Derive submenu in the Collections Result set context toolbar.
This property contains the full or relative path to the database you want to link to, without the name of the file. You don't have to fill in this property manually: just select a database in the next option, and the relative path to that folder is automatically entered here. Usually, you keep your databases in one folder, and the relative path you'll often encounter here is: ../data.
Instead of a path to a local database folder, you may enter a base query URL to an HTTP handler (gateway) for an external source, if you want to be able to derive records from that external source. See the Help topic "Approaching external sources as friendly databases" for more information.
First, enter or search for the name of the existing database (an .inf file) that you want to link to. Do not enter the extension of the file. Examples of database names are document, copies, and collect. (This option does not apply to external sources accessed via a gateway.)
Important: when you work in a copy of your live application, then make sure you search the right folder (in the copy) for the proper file: otherwise the relative path will be incorrect when you place back this copy as your live application later on.
If the database that you select has datasets defined for it, these datasets will be listed in the Dataset drop-down list. (Some databases, like the thesaurus, have no datasets.) Typically, you select a dataset if for this link you only want to retrieve data from that specific dataset.
There is a difference between linked field processing for records derived from a dataset in the current database and records derived from another database (or dataset in another database), namely that in the first case for reference linked fields the link references (record numbers of linked authority file records) and only these references are copied to the new record. This is the optimal solution because the new record will contain the same reference as the original, and we can be sure the reference can be resolved and that merged fields can be retrieved because both records exist in the same database and will use the same authority files.
But in the second case we cannot be sure whether the other database uses the same authority files as the current. Therefore we can't just copy the link reference to the new record: after all, it might refer to a completely different record. So, in this case only the linked values and merged field values themselves are copied to the new record. The existing link reference will not be copied along, and neither will a new reference link be created directly and automatically for the value in the new record; the latter being important for authority files linked to the current database, which have non-unique indexes. An automatic reverse resolving of a non-unique value would pick the first authority record number for that value, while that may be the wrong one. On saving the new record, all linked fields will automatically be reverse resolved to the authority files linked to the current database, but you'll have to manually select the proper authority records for terms which are not unique, before the record can be saved.
Collections ignores this setting and will display the regular Search dialog for the data source that has the same database/dataset associated with it as this friendly database. So the available access points will come from that data source.
If the search for a record to derive results in more than one record, then these records will be listed in a separate window using the brief display screen set up for the data source that has the same database/dataset associated with it as this friendly database. Collections will ignore any differently set screen in this option.
To display all details of a record from the found records list when the user clicks the Details button for a selected record, Collections uses all detail screens set up for the data source that has the same database/dataset associated with it as this friendly database. Collections will ignore any differently set screen in this option.
Remove original record after retrieval
If you do not want to keep the (original) record that a user derives from the friendly database, you mark this checkbox.
If you leave the checkbox unmarked, deriving a record will copy it, leaving the original in place.
(This option does not apply to external sources accessed via a gateway.)
After derival procedure (ignore "After")
It is possible, if desired, to have an adapl executed just before and just after a record has been derived (still before storage), to change something about the copied data for example. So the adapl you set here is executed twice. In your ADAPL code, use the &1execution codes24 and 26 to determine if the adapl is executed before or after derival. Also see the reserved variables&0, &0[2] and &0[3].
Feedback
