On the Procedures tab, which is present when you have selected a new or existing database, you can specify adapls that have to be executed automatically after a user performs a certain action on this database in a Collections application. For an existing database some of these procedures will already have been set; for a new application you will probably have to write adapls yourself, before you can set them as a database procedure here. Of course you can add existing procedures or choose different ones whenever necessary.

You can even change the existing adapls to which these properties refer. But do consider that an adapl might be used by different databases, so changing an adapl might have undesired effects elsewhere.

You can link adapls to databases (.inf's) as well as to screens. Adapls linked to screens have priority over those specified for databases.

Click here for information on how to edit properties in general. On the current tab you'll find the following settings:

Storage procedure

If Collections is to carry out an ADAPL procedure each time a record is saved or deleted, then enter the name of that adapl (without the .bin extension) here. The adapl will only be run when the save or delete command is definitive, i.e. after the user has confirmed the action. The adapl will always be run twice though, once just before storage (after user confirmation) and once just after storage. To prevent certain fragments of code from being run twice, use the &1 reserved variable (in an IF ... THEN construction) to find out when the adapl is being run: before storage (&1 = 11) or after storage (&1 = 14).
Note that the adapl is also executed before the reverse side of any internal link has been processed: in an archive for instance, if you create a new item record, link it to some parent record and save the item record, then the storage procedure will be executed before the parent record is updated with the narrower link to the new item record! The same applies when you would delete an item record which was already linked to a parent or when you would change an existing link to a parent record. This is relevant when you want to use the storage adapl to process data from the linked narrower records in the parent record: the linked narrowers might still change after this adapl has finished and the current narrower record has really been saved. Therefore, try to program this type of code in an after-storage section to avoid this problem altogether. But then you do have to use FACS if you want to write anything to the currently stored record: before storage you can just assign values to the field tags themselves, because the record is technically still in edit mode.
For each imported record through the Collections Import functionality, whether just updated or created newly, the storage procedure will be executed too. Storage adapls are not executed when data is imported using Axiell Designer or import.exe. A task in Axiell Collections will also execute a storage adapl if the task adapl writes or edits records.
If a record is deleted (after confirmation) the storage adapl will also be run. By using the ADAPL SELECT NO statement, you can prevent users from deleting certain records. Again, use the &1 reserved variable as a condition before running deletion-specific code: before deletion (&1 = 12) or after deletion (&1 = 15).

If a screen is linked to both an after-retrieval adapl and a storage adapl, the after-retrieval is run first, and only when the record is saved (after confirmation) the storage adapl will be run.

Note that records which are stored using the Axiell WebAPI (wwwopac.ashx) do not trigger this storage procedure by default: in the adlibweb.xml configuration file for the API, set the adaplEnabled option to True to reverse this.

So, before-storage, after-storage, before-deletion and after-deletion procedures are supported by Axiell Collections. From Collections 1.11, a storage procedure set up for a reversely linked database is executed as well when either:

After retrieval procedure

This is a procedure that is carried out after a record is retrieved. This can be useful if records are being retrieved for the Result set but it has effect on all views displaying the record. For example, you could use it if you want to enforce a certain punctuation in value with the aid of an adapl, before records are displayed.
An after retrieval procedure is executed separately for every record visible on the screen: this is relevant if you associate the adapl with a brief display screen. If you scroll downwards in the Result set view and new records become visible, the after retrieval adapl will be executed for the newly visible records as well.
Since the adapl is executed before record data is being displayed, this might have consequences for the performance of the screen build up. So make sure you keep an after retrieval adapl as light as possible.
Note that if you change a value this way, it is only changed for display (so the change won't be stored) but at the same time the user won't be able to see or find out what the really stored value was: when a record is put in edit mode, still the changed value is shown and if the record is saved the changed value will still be stored and will then overwrite the original value. So be very careful with implementing after-retrieval procedures for Collections.
Also note that errorm messages won't show after retrieval.

Copy record procedure

Directly after copying a record, this procedure is executed. Typically it is used to delete unique data in the new record, so that the user is forced to enter new data. An example is the Copy details field group in the Library catalogue.

Input record procedure

This is called just before an empty, new record is displayed on screen (e.g. when you click the New record icon). The procedure is used, for example, to preset fields with specified values.

Before-input procedures are supported by Axiell Collections from version 1.0.6100.28025.

Edit record procedure

This procedure is called when you are going to change a record (also when copying a record), for example right after you click the Edit mode icon in Collections, or if you move between tabs when creating a new record. The procedure is also executed before changes are made through an automatic search-and-replace action or change location procedure started by the user, but not before internally linked records are updated.

Before-edit procedures are supported by Axiell Collections as well (from version 1.0.6100.28025). From Collections 1.11, an edit procedure set up for a reversely linked database is executed as well when either:

From Collections 1.12, a select no in a before-edit adapl prevents the record from going into edit mode and leaves no lock. A red warning will appear with the text: Not allowed to edit record <priref>. You could precede the select no with an errorm without severity code or with severity code 1 (both giving an orange message) to explain to the user why the record is not allowed into edit mode. Instead of this construction though, you could also use a single errorm with severity code 2, which prevents edit mode as well and allows you to explain the reason why at the same time.

Field based procedure

This adapl is carried out before or after data is entered or edited in a specific field. You set this in the Data validation property of the entry field on a screen, that you want to validate with this field based procedure.
If the screen field (that uses this adapl as an after-field adapl) is associated with a linked field, and the user just entered a different existing linked term in the field and leaves it, then the after-field adapl will be executed before the link has been resolved: this means that when the adapl runs, no link reference or merged-in values are available yet, just the linked value itself. If the screen field that is associated with a linked field is in a table grid, then as long as the value in that field has not been stored (by saving the record), an after-field adapl (running for another field) always sees the linked field as empty.
Also note that a field based procedure won't be executed if the user performs a search-and-replace in the field that uses this adapl.

After-field procedures are supported by Axiell Collections from version 1.0.6100.28025. After-field procedures for fields which are not in a table grid, do not have access to data in table grids that has been entered while editing this record: such procedures only have access to already saved data in table grids.
Also, for an after-field adapl for a field in a table grid, any other occurrences of this field than the currently left one, are non-existent to the adapl, so the adapl behaves as if the currently left field (group) occurrence is the only one. So after-field code can't do anything with the data from the other occurrences and the data from the rest of the record is not available either to this adapl.