Release notes 7.7

Below you'll find a brief overview of new functionality implemented in Axiell Designer 7.7.#, including links to more information.

Backwards compatibility

Using new (Collections-only) Designer settings in your application and database definitions will always break compatibility with older versions of Designer and Collections and other Axiell software* using the same BaseAPI, although removing those new settings will often restore that compatibility under the condition that the SQL table structures haven't changed because of those settings: if the SQL table structures have changed too, then a SQL database backup from before that change is required as well to go back to the previous state. The Designer release notes always note the compatible version of Designer and Collections, but this applies to below list of other Axiell software too. For a full list of compatibility issues through the different versions of Designer and Collections, see the Axiell Designer compatibility topic. The Axiell software which needs to be updated to the latest version once new Designer settings have been applied (only if you have a license for that software of course) is the following: Collections, AdMove server, Workflow client, Ingest, WebAPI, SDK, AnalyzeData, Migration, ConvertInternalLinks, IndexCheck, InternalLinkCheck, LinkRefCheck, RemoveLanguageFromData, RemoveTagsFromData, DBtool and ValidateDatabase.

New options and functions for Axiell Collections make further use of Adlib for Windows impossible

New settings in Axiell Designer pertain only to applications run within an Axiell Collections environment. If such new settings are applied, then the resulting application can no longer (reliably) be opened in Adlib for Windows. Since development of Adlib for Windows has ceased quite a long time ago, these new options are not supported by Adlib for Windows. Even if Adlib would ignore the relevant option, you could no longer reliably work in Adlib too, so altered applications using Collections-only functionality should never be opened in Adlib again.

Contents

Additions and changes to XML documentation

New option for default search filter on linked field

New &1[4] reserved variable to identify the process that started a before-storage adapl

WebAPI XML payload functionality supported in ADAPL

Spanish, Hungarian and Catalan added to optional application languages

Conditional suppression of download possibility in application and image fields

Alphanumerical sorting added to REPSORT function

New WHERE option for ADAPL FACS READ to fetch records using an advanced search statement

A FACS READ NEXT USING can now be abbreviated to a READ NEXT

New &W reserved variable contains number of hits from last FACS READ

New ADAPL COUNT function to count field occurrences matching a condition

Setting up record merging per data source

Finding and linking orphaned labels

New optional indexed link table structure for heavily used linked fields

New Media type tag property for image and application fields

A substituting Original filename tag property for image and application fields

New &1 execution codes 30 and 29

Copy record and Record template methods added

Enumerative fields can no longer accidentally be made multilingual anymore

Field inheritance now enforced for entire field group

Allowing non-media file downloads from an image field linked to a DAMS

Making a linked field validable on more than one field

Using adapl-only output formats for PDF and plain text printouts

Image and application fields path properties now available in field list grid view

yesno ADAPL function now supported

Link screen adapl supported in Collections 1.10

Using the Destination dataset field property

Numeric field properties

Disable download of images

Errorm messages in different colours

A formatting option for integer fields

Having adapl-created documents uploaded to a repository via Collections

Prompted output formats for Axiell Collections

New ADAPL function: GUID

Importing data into a database with None default access rights

2022-04-07: release notes Axiell Designer 7.7.5

The following bug fixes for Designer 7.7.5 and new functionality for Axiell Collections version 1.13 have been implemented:

Bug report no.

Short problem description

AX-343

Reindexing an index with a domain name tag only indexed the last domain value from each record, while all domains from the record and the value without domain should have been indexed.

AX-338

The ADAPL compiler didn't work anymore: missing adaplu.dll.

AX-333

The following deprecated database documentation stylesheets have been removed: EnumFieldsValueList To Csv.xsl, Fieldlist To Csv.xsl, LinkedFieldsList To Csv.xsl.

AX-332

The Record lock manager could no longer be opened.

AX-330

A NullReferenceException error was generated when copying a linked field to a task field list, in the Application browser.

AX-327

When creating a new database (using the Reindex all tables option) no record locks table was created.

AX-290

Errors 357 (DBS_import) or 2 (Out of memory) appeared when running certain XML update imports via Designer.

AX-123

Assigning access rights to multiple enumerative values at once (by Ctrl+clicking the relevant enumerative values and assigning them access rights via the right-click pop-up menu) didn't work: the access rights were only assigned to the last selected value.

2022-04-07: additions and changes to XML documentation

In the Application browser, right-click a single screen reference (in a data source) or a single screen file in the \screens folder and select Create documentation in the pop-up menu to create documentation about that screen, or right-click the \screens folder (or another folder containing screen files) and select Create documentation in the pop-up menu to create documentation all screens in that folder. The View menu in the Documentation window offers several formats to convert the documentation result to. New additions are:

A Mandatory Fields List (CSV).xsl XML documentation stylesheet was added. The stylesheet lists all the mandatory fields on the screen(s) with their properties. It works on a single screen or on all screens in a folder.
A Fields List (CSV).xsl XML documentation stylesheet was added. The stylesheet lists all the data fields on the screen(s) with their properties. It works on a single screen or on all screens in a folder.
Screen Info - Comparison Mode - English Only (XML).xsl and a Screen Info - Comparison Mode - Dutch Only (XML).xsl XML documentation stylesheets were added for screen comparison. These stylesheets create documentation for one or more screen definition (.fmt) files. The documentation has been optimized for the comparison of screen definition properties. It only lists texts and labels in a single language; the stylesheet name indicates which language will be listed. A screen comparison using this stylesheet therefore ignores differences in translations. Some properties that are irrelevant to a comparison are being omitted, namely:
- information on the creation of the documentation file itself;
- information on the Designer version used to create the documentation file;
- information on the location or dating of the .fmt file(s).

An updated documentation format for .inf files:

The Enumerative Field List (CSV).xsl XML documentation stylesheet was updated to also include the recently added application languages Spanish (15), Hungarian (16), and Catalan (17).

2022-04-07: new option for default search filter on linked field

The values which can be selected for a linked field can be limited by the application manager to a fixed or variable domain, to force users to pick an appropriate value for this field. Similarly you would sometimes like to limit the offered list of values even more or differently, based on an advanced search. For example, for databases that have multiple record levels (e.g. archives/film), it is only relevant to see the item-level records when attaching items to a loan. In that case you'd like only item records to be presented in the list of records to link to. One may also want to pre-limit that list to items that are actually available (i.e. items without lending restrictions or condition problems) so that an unavailable item isn't inadvertently selected by the user.

From Designer 7.7.5.3038, therefore a new Search filter option is available on the Linked field properties tab of a linked field. In it you can specify any advanced search query you'd like to apply always when a list of available values for this linked field is retrieved from the relevant linked database, for example when the user starts typing in the linked field and the auto-complete drop-down opens for the user to pick a value from or when the user opens the Find data for the field window to search for a list of available values. Also when using the Extend search option from within the Find data for the field window, will the filter will be applied to the list of found records.

DSDefaultSearchFilter

The Search filter you set here, will be additional to any domain and lookup field you set for this linked field.

Also, the filter won't be visible in the Collections user interface anywhere. In many cases you probably don’t want that anyway if you have set a search filter based on sensitive information (the object value, for instance).

Collections version 1.13 or higher is required to handle this functionality. Note that if you set this option, you'll also have to update all other Axiell software!

2022-04-07:new &1[4] reserved variable to identify the process that started a before-storage adapl

In a before-storage adapl it is sometimes handy to know which process caused the execution of the adapl, because you'd like certain code to be executed for one process but not for another. Although the adapl is associated with an .inf (database table specification), there might be different reasons for its execution: the WebAPI may have written a record in the database or the Move app did, or an import process has inserted new records, for example.

Therefore now the &1[4] reserved variable has been introduced. In a before-storage adapl this will contain a number ranging from 0 to 6 to indicate which process caused the adapl execution:

&1[4] value

Cause for adapl execution

0

This is the default value. It's the generic value for Axiell and Adlib products.

1

Axiell Collections (from version 1.13)

2

Axiell WebAPI (from version 3.1.1.1298)

3

Axiell Move server (from version 3.0.2287.1)

4

Axiell Migration (from version 3.0.2287.1)

5

Axiell SDK (from version 1.10.1.1329)

6

Import jobs started from Axiell Collections (from version 1.13)

This addition is independent of Designer or adapl.exe version.

2022-01-18: release notes Axiell Designer 7.7.4

The following bug fixes for Designer 7.7.4 and new functionality for Axiell Collections version 1.12 have been implemented:

Bug report no.

Short problem description

AX-295

When there was only one field in a csv file to be imported and this field was mapped to %0, the import returned an error: Empty CSV record on line 1, record not imported.

AX-291

Creating a new field failed when the tag already existed as the field name of another field.

AX-288

A main window read error on a linked database didn't report the database of the linked field.

AX-284

The application tester gave an incorrect error report on a missing index on a merged-in linkref field.

AX-275

When copy-pasting a linked field to the fields list of a prompted output format, an unhandled exception occurred.

AX-273

When saving database changes, Axiell Designer now checks if all the required tables exist and creates any missing tables. Only when running in administrator mode, though.

AX-272

The Object searcher didn't find Original file name tags.

AX-271

The XML Documentation stylesheet Application and Image Field List (CSV) has been updated to now report the actual Download path property (instead of a placeholder value).

AX-270

In the XML database documentation the Application field property Media Type Tag was missing.

AX-269

In the XML database documentation the Application field property Original Filename Tag was missing.

AX-268

In the XML database documentation the Image field property Media Type Tag was missing.

AX-267

In the XML database documentation the Image field property Original Filename Tag was missing.

AX-266

New XML Documentation stylesheet Feedback Database Definitions List (CSV) has been added.

AX-264

An output stylesheet path was not included in the XML documentation.

AX-263

When trying to save an .inf file, Designer would check the connection to the database and did not save the file but returned an error instead.

AX-255

An empty folder for future ApplicationInfo stylesheets has been added and new stylesheets for database documentation have been added to the Xsl\DatabaseInfo folder and the existing ones have been replaced. It concerns:
 
Database Info - Comparison Mode (XML)
Linked Field List (CSV)
Screen Field Group List (CSV)

AX-254

If you loaded any database with enumerative fields in the Translation manager (e.g. a thesaurus database, field do), then for enumeration value texts, the Tag column remained empty.

AX-253

Translation manager: (reverse) relation texts were not loaded from .inf files.

AX-252

Translation Manager: screen texts for HTML fields and system fields *J were not loaded.

AX-251

For texts from adlib.pbk files, the Translation manager couldn't show the data source the text was connected to, which made it hard to identify the correct text.
For methods, output jobs, tasks etc. the name of the data source is now added to the Path column data.

AX-250

Translation Manager: adlib.pbk Tasks and Connections nodes texts were not loaded.

AX-244

When clicking the empty row at the bottom of an enumerative list, an error was generated.

AX-225

It was not possible to force a specific role for running import jobs. (This is required for environments where running in elevated Administrator mode is not allowed.)
Fixed in Axiell Designer version 7.7.4.2134 and import.exe version 7.6.21161.1. With the new fixed field mapping you can now steer what role is used for running the import job. When you add the following in the field mapping list you can set the role:
 
Source field                 |           Destination field
MY_PARTICULAR_ROLE               <ROLE>
 
So, the Source field column must contain a role known in the application (so instead of MY_PARTICULAR_ROLE, use an actual useful role name), under which the import must and can run, and the Destination column holds the reserved mapping id <ROLE>. This is a fixed string so enter the text <ROLE> literally. The runner will pick this up when run from Axiell Designer or using the command line import tool.

AX-219

New stylesheets for database documentation have been added to the Xsl\DatabaseInfo folder and the existing ones have been replaced. It concerns:
 
Application and Image Field List (CSV)
Autonumber Field List (CSV)
Database Info - Sorted On Name (XML)
Database Info - Sorted On Tag (XML)
Enumerative Field List (CSV)
Field Access Rights List (CSV)
Field List (CSV)
Linked Field List (CSV)
Multilingual Field List (CSV)
URI Field List (CSV)

AX-205

The XML documentation field property element <presentationformat> lacked a name attribute.
The <presentationformat> property is included for data types DateIso and Integer, with an attribute "name". For the data type Numeric the property is not used anymore, so it is not included in the documentation.

AX-204

The Application browser documentation functionality didn't list all translations of an External source name.

AX-203

Metadata properties were not included in XML documentation.

AX-157

An Object Search action on roles didn't return access rights for enumerative values.

AX-132

Copying and pasting an import or export job in the Import/Export jobs manager produced an empty import or export job.

AX-121

The Object Searcher didn't find roles in enumerative values.

AX-109

The Object Searcher didn't report any "include" field definitions, as can be defined per dataset.

AX-76

Application field specific properties were missing from the XML database documentation.

AX-75

Image field specific properties were missing from the XML database documentation.

AX-33
AX-90

Default values could not be set individually for so-called included fields: the default values were automatically copied to the same included field in other datasets.

CV1-3651

In a before-edit adapl, a select no or errorm with severity code 2 would leave a lock on the record, even if it didn't go into edit mode (as intended).

With the fix in 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.

2022-01-18: WebAPI XML payload functionality supported in ADAPL

The Axiell WebAPI 3.0.21344.1 and higher support the processing of posted XML payloads to extract their data to write or update Axiell database records using an adapl.
Imagine for example some media ingest software which generates metadata about the result of an ingest action, in the form of a snippet of raw XML or JSON, with the purpose of having some or all of the information in such a file processed in certain Axiell database records, maybe in the media records that were just created or in object records linking to those media records or maybe in some new event records.
The Axiell WebAPI is now capable of requesting such processing with the load command and the payload argument. The processing of the posted XML file itself however, must be done via a custom adapl. A new <payloadConfiguration> section in the WebAPI adlibweb.xml configuration file specifies the Axiell database name and (location of) the adapl to use, tying it all together. So a raw XML or JSON file posted with a wwwopac.ashx?command=load&payload=my_payload_type1 request would process the posted file according to the my_payload_type1 configuration, using a custom adapl for a specific database, as set in the adlibweb.xml.

For ADAPL to support this functionality, the existing indirection functionality (using the prefix exclamation mark to treat the contents of a text variable or string as if it were a field tag) can now also be used to extract data from an xpath node. Simply provide the xpath path to the desired elements in the XML DOM node, preceded by the payload keyword as identifier to the payload and a space, as a string in a text variable for example and use indirection to retrieve the contents of the node: in this context, the contents are only any textual value directly underneath the specified element, so any subnodes (their element names nor their contents) are not considered contents here. You can also count "occurrences" of a provided xpath element, using repcnt, to find out how often a certain node appears in the payload XML, but note that repcnt counts the total number in the file: you cannot recursively count subnodes per some higher node. An example of an adapl counting the number of mavis/DigitalCarrier nodes in the file, which then retrieves the value of the xl:href attribute of the first DigitalCarrier node, then also counts the number of mavis/DigitalCarrier/objectResourceIdentifiers/ResourceIdentifier/resourceIdentifierType nodes, after which of each of those nodes its content is retrieved can be seen below. Note that the xpath text variable can have any name, it doesn't need to be xpath.

 

* payload test adapl

text xpath[0]
integer occ, maxocc

xpath = 'payload mavis/DigitalCarrier'
errorm 'Count = ' + repcnt(!xpath);
if (repcnt(!xpath) > 0) {
 xpath = 'payload mavis/DigitalCarrier/@xl:href'
 errorm 'First digital carrier href: ' + !xpath
}

xpath =  'payload mavis/DigitalCarrier/objectResourceIdentifiers/ResourceIdentifier/resourceIdentifierType';
maxocc = repcnt(!xpath);
occ = 1
while (occ <= maxocc) {
 errorm 'Occ[' + occ + ']=' + !xpath[occ]
 occ = occ + 1
}

end

So !xpath retrieves the value of the first node, while !xpath[occ] retrieves a specific occurrence of the node. An attribute of an element can be retrieved with the @ prefix: this works with or without attribute namespace.

The errorm texts produced by this payload adapl will end up in the WebAPI response, but only if the <debug>true</debug> setting has been made in the adlibweb.xml configuration file.

When a WebAPI load request is executed, in memory a new blank record is created for the specified database and the adapl is run for that record, so besides generating errorm messages you can use the adapl to assign data from XML nodes to field tags in the record as you would normally assign values to field tags in e.g. a before-storage adapl. To save the new record, include a write _LOCAL statement in the adapl after all relevant data has been assigned to field tags. Leave out the write _LOCAL statement if you don't want to create a new record in the currently relevant database.
You can also (regardless of what you do with the new record in memory) use the ADAPL FACS functionality to read, update or create records in FACS databases that you specify using regular FACS definitions in the adapl.

There's also a new &1 execution code value for payload adapls: 31. So if not all code in your custom adapl is meant for payload processing, you can enclose the payload section by an if (&1 = 31) { ... } condition and the other code by other &1 conditions.

2021-11-15: Spanish, Hungarian and Catalan added to optional application languages

From Designer 7.7.4.2727, three new optional application languages have been added: Spanish, Hungarian and Catalan. Translations of all application texts in these languages can be edited in the Translations manager. Collections 1.12 is required for display of the application texts in these languages: system texts are also available in said languages.
As soon as application texts in these languages have been added, backwards compatibility of the files which hold those texts is broken, so older versions of Designer and Collections cannot open screens or application structures once Spanish, Hungarian or Catalan texts have been added.

2021-11-03: conditional suppression of download possibility in application and image fields

On the Application field properties tab of an application field and the Image properties tab of an image field in database definition. (.inf), a new Disable download condition option has been added to disable the download button next to all occurrences of an image field or application field in a displayed record in Collections conditionally (and thereby disable the possibility to download the images or files registered in those occurrences). In the Disable download condition property you can enter a condition with a format equal to that used for conditional screens and fields, so you could disable the download button by means of a complex condition, e.g. by user role or by field values. When the conditional expression evaluates to true, the download button will be disabled.

Marking the existing Disable download checkbox will always disable the download button for this field and therefore takes precedence over the new Disable download condition property (which will be greyed out in that case).

DSConditionalDownload

Note that if you set a download button suppression condition for a linked image or application field, then you should also set it for the source image or application field in the linked database, otherwise the download button will still always be available in the media record itself (if the user has access to it) and in the zoom screen when the user clicks the underlined link to the media record.

Use of this new option breaks backwards compatibility of this .inf, but emptying the option would restore that compatibility.

2021-10-14: alphanumerical sorting added to REPSORT function

A sort mode value 3, to indicate alphanumerical sorting, has been added to the REPSORT function. Other supported options for alphanumerical sorting are +8 (so use value 11) to indicate a descending sort order and +1024 (so use value 1027) to ignore accents.

2021-10-06: new WHERE option for ADAPL FACS READ to fetch records using an advanced search statement

In ADAPL, FACS READ statements have always been limited to either subsequently reading each record in the FACS database, each record in an index in the FACS database, each record matching a certain index value in the FACS database or each record in a saved search (aka pointer file) in the FACS database. This meant that ADAPL had no way to only fetch records that matched multiple conditions. For output formats using adapls this had the consequence that in such cases the user had to perform the proper search in Collections already, possibly apply a specific sorting and mark the desired records, before printing to the output format.

This restriction has now been removed with the introduction of the WHERE option for a FACS READ. Syntax:

READ <FACS name> WHERE '<advanced search statement>'

The advanced search statement can be any query you would normally use in Collections, including any sort option if desired. It uses field tags or English field names from the .inf that is referenced by the FACS declaration: it does not use FACS field aliases. Keys to search on must be enclosed by double quotes (or double single quotes), while the entire search statement must be enclosed by single quotes. For maximum flexibility you don't need to enter a fixed query string behind WHERE: you can also put toghether the advanced search statement in a text variable and then use the text variable (without single quotes around it) as the WHERE argument. This allows you to include e.g. user input (obtained via a parameters screen for a task or output format) or values from the currently processed record in the advanced search.
A sorted query works out the same as in Collections, so note that if the sort field has multiple occurrences, sorting takes place on the value with the highest value (for descending sorting) or lowest value (for ascending sorting).
Besides the obvious use to only fetch records that match the result set of an advanced search, you could well use this functionality for statistical purposes, to calculate sums of insurance values or total volumes etc.

When you perform the READ WHERE for the first time during an adapl run, only the first record of the resulting set will be available in the FACS buffer, so you can use the relevant FACS aliases from your FACS declaration to obtain values from the fetched record. To fetch the next record from the result set, simply use:

READ <FACS name> NEXT

(Pointers to the complete result set are kept in memory after the first READ WHERE, so the following READ NEXT automatically uses that list to fetch the next record without having to execute the advanced search again.)

Example of an adapl-only output format for any data source (no record needs to be selected):

fdstart COLLECT '../data+collect'
 %0 is COL_priref
 IN is COL_object_number
 OB is COL_objectname
 VV is COL_creator
fdend

open COLLECT noreset
 if (&E <> 0) {
   errorm 'Error opening database COLLECT, code = ' + &E
   end
   }

text searchstringvar[0]
searchstringvar = 'object_name = * and VV = "Mondriaan, Piet" sort OB'

read COLLECT where searchstringvar
while (&E = 0) {
 print 5, 70, COL_objectname
 output
 print 5, 70, COL_creator
 output line
read COLLECT next
}

end

2021-10-06: a FACS READ NEXT USING can now be abbreviated to a READ NEXT

If records from a FACS search in an index, e.g. read COLLECT using COL_objectname = 'chair', are subsequently read by a READ NEXT USING in a loop, e.g. read COLLECT next using COL_objectname = 'chair', then you could now abbreviate that next read to just a READ NEXT, e.g. read COLLECT next. The adapl processor will retrieve pointers to the complete result set from the initial READ <FACS name A> USING ... and will remember it for any following READ <FACS name A> NEXT, so the next record will automatically be read by using that list: the index search won't be executed again.
Still, the verbose way of formulating the next READ is not slower than the new abbreviated way, because the old way used the initially retrieved pointers list as well. You can still use the old syntax too.

2021-10-06: new &W reserved variable contains number of hits from last FACS READ

In ADAPL you'd sometimes like to know how many hits a certain FACS READ operation has generated. That number is now available in the new &W reserved variable. The variable is not influenced by a READ NEXT and it doesn't need to be called directly after the READ, but some time later is fine too. The number in &W always pertains to the last executed READ WHERE, READ USING or READ POINTER. The number is stored in the variable as a string, not as an integer, so if you want to do a calculation with the number, you must convert it to an integer first, using int(val(&W)).

A partial ADAPL example of an adapl-only output format which reads all records with an object number and then prints the number of retrieved records:

read COLLECT using COL_object_number = '*'
print 5, 70, 'Hits: ' + &W
output

2021-10-06: new ADAPL COUNT function to count field occurrences matching a condition

Syntax

result = COUNT(FACS_name, '<search statement>')

Arguments

result: integer

FACS_name: FACS database name

search statement: text

Meaning

COUNT (available from Designer 7.7.4.2658, adapl.exe 7.6.21279.1 and Collections 1.12, not compatible with Adlib) counts the number of field occurrences or field group occurrences matching the search statement in the named, open FACS record or in a _LOCAL record (to address the currently open database). The search statement can be something similar to an advanced search:

the syntax of a singular search is: field operator value
operators can be =, <, >, >= and <=
multiple singular searches can be combined with AND, AND NOT, OR and WHEN
WHEN can only be used on grouped fields and WHEN can be used more than once in a search statement

Example

number = count(COLLECT, 'kj=Lang* when ki=person when kn=retired')

Result

number takes as value the number of field group occurrences in which a field tag kj has the truncated value 'Lan' whilst the same occurrence of field tags ki and kn have the values 'person' and 'retired' respectively.

kj

ki

kn

Lang, Howard

person

retired

Lange, Erik

person

active

Lansing, Jack

person

retired

If the relevant field group would contain the data above, number would result in 1.

2021-06-01: setting up record merging per data source

Sometimes you may have two or more records describing the same person, the same thesaurus term or the same catalogue item or object, for example, and you'd like them merged into one, taking all the best data from those records and automatically delete the remaining ones. Collections 1.12 now offers just that functionality and gives you control over target and source record(s) and to a certain extent over which data you'd like to keep and which must be deleted. The functionality is only present if properly set up for a data source.

This simply involves adding the new RecordMerge method to the existing list of methods in the desired data source(s). Name the method something like "Record merging". You can assign access rights to limit the use of this function and that is certainly recommended. Roles which haven't been assigned access rights to this method will have full access to the function. Without the method, the function won't be available to users in the current data source.
There are good reasons to limit the use of this function because the function can't check if mandatory fields will be filled in after the merge and if non-repeatable fields haven't been assigned multiple occurrences during the merge: see the Collections release notes for version 1.12 for more information about these limitations. So merging records should only be done by knowledgeable users.

After adding the method and recycling the application pool, the Merge selected records (Ctrl+H) icon becomes available in the Result set context toolbar of Collections. The user should mark at least two records to activate the icon.

ACRecordMerging02

Using the new method breaks backwards compatibility, but removing the method restores it.

2021-05-06: release Axiell Designer 7.7.3.1790

Today we release an update for Axiell Designer 7.7.3 (build 7.7.3.1790), offering the bug fix and new functionality described below. Axiell Designer can be downloaded from Hornbill: see the FAQs section.

Bug report no.

Short problem description

AX-119

There was an exception when re-indexing all indexes in the data folder, of the type: The statistics 'auction_record_access_stat_priref_role' is dependent on column 'role'.

2021-04-29: finding and linking orphaned labels

Because of the new way in which screen tabs are rendered in Collections 1.11.0 and up, and the challenges so-called orphaned labels pose (an orphaned label is a label without an associated field), it has become more important to be able to find out which labels on which screens are such orphaned labels: normally when you place a field on a screen in design mode you get an associated label with it and for the new screen rendering it is important that labels are associated with a particular field, but Designer has also always allowed you to place just a label on a screen, so to be able to find those screens and labels easily now, screens with orphaned labels underneath a data source (not in the \screens folder though), are marked orange and if you open such a screen in the Screen editor the orphaned labels themselves are marked with an orange border too.

DSOrangeLabelBorder2

DSOrangeLabelBorder1

If your screen with orphaned labels displays fine, it doesn't need changing of course, but if you find that display is problematic you could try adjusting the screen using the following considerations (do keep a backup of your original .fmt screen files):

From this version of Designer, an orphaned label can be associated with an orphaned field (saving you the work of having to create a new, identical field with associated label). Although an orphaned label now has an orange border in design mode, an orphaned field (a field without associated label) has no visual marking, but you can often guess the field if it has an orphaned label in front of it or above it. To be sure, select both an orphaned label and a presumed orphaned field which you think should belong together: do this by first clicking e.g. the label, then press the Ctrl key and click the desired field, although the other way around works fine too. Now right-click one of the two selected fields. If the pop-up menu shows an active Link label to field option, you have indeed selected both an orphaned field and an orphaned label. (The option won't be active if either or neither of the two fields is orphaned.)
 
DSOrangeLabelBorder3
 
Click the Link label to field option to actually associate the label with the field. You'll notice that the relevant label no longer has an orange border because it is no longer orphaned. Save the screen to make the connection between label and field permanent.
 
DSOrangeLabelBorder4
If you have a situation like above, where the orphaned row labels cannot logically be associated with any field (because the column labels already have a claim on those), then you may need to consider a different solution. You could create a separate box for the Consists of field group for example. Then the first box can be named Part of and the second Consists of, while the second box can also have duplicates of the column labels from the first box.
Of a horizontally oriented field group (fields placed next to each other), you may consider placing it in a box without other fields in it (or move any other fields out of the current box by cutting the fields via the right-click pop-up menu (which also cuts the associated label), then pasting them in an empty area at the bottom or on the side of the screen and then dragging them - the label first, then the field, otherwise the label may disappear on you - to their new box or location), turning it into a table grid by right-clicking the box, selecting Properties in the pop-up menu and marking the Edit link group on demand option for it. A table grid has performance advantages too.
If the solutions above are not suitable, you can also try to move the orphaned label to a different position to see if that helps in the display in Collections. If not, you can still delete a selected orphaned label via the right-click pop-up menu. Since it is a stand-alone label, no field will be deleted when you do that, only the label will be removed.
Before deleting a stand-alone label consider the fact that it may have useful translations. You can copy those translations by right-clicking the label, selecting Properties, then right-clicking the translations list and selecting Copy texts in the pop-up menu. You can paste these copied texts into another label in the same way, but then choose Paste texts in the pop-up menu.
Indented positions of fields and labels may be lost in the final display, so try to position the fields and labels in a spot without a leading empty space.

2021-04-28: release Axiell Designer 7.7.3.1670

Today we release Axiell Designer 7.7.3 (build 7.7.3.1670), offering the bug fixes and new functionality described below. Axiell Designer can be downloaded from Hornbill: see the FAQs section.

The following bug fixes and new functionality for Axiell Collections version 1.11 have been implemented.

Bug report no.

Short problem description

AX-217

The Application browser documentation functionality didn't  correctly save the results for an XSLT that produced XML. The result was differently sorted than displayed in the Documentation window.

AX-212

During the execution of a specific import job for differently formatted import files, the Import job manager generated an 172Object newer version error.

AX-201

The Designer Import tool allowed the import of non-existing fields, creating invalid records (which cannot be edited or deleted) because all field tags present in a record should have been defined in the relevant data dictionary (.inf file).
The fix now validates the Destination field mapping against the target data dictionary and reports errors like this when trying to execute the import job:
import error '1', info: 'Tag 'TI' not found in database 'thesau'; field ignored.'
import error '1', info: 'Tag 'Df' not found in database 'thesau'; field ignored.'
import error '1', info: 'Tag 'TY' not found in database 'thesau'; field ignored.'
import error '1', info: 'Import stopped on record 0, error code = 1'

2021-03-09: new optional indexed link table structure for heavily used linked fields

The text below is the original functionality description. For the latest, updated version of this text, please clickhere.

If you have records with hundreds or thousands of reverse or hierarchical links to other records, like a loan record with many links to object records, or archive records with many child records for example, then opening, editing and saving such a record can take a very long time. To solve that problem, a new, optional SQL table structure has been designed, especially for heavily used linked fields, which can be implemented from Designer 7.7.3 (although importing data via Designer or import.exe does not support this table structure yet (06-05-2021), only imports through Collections or Axiell Migration are supported). If implemented in your databases this will lead to an enormous improvement in performance when it comes to processing such records. A requirement for the performance improvement though is that such linked field groups are displayed in table grids, because only then is it possible for Collections to resolve only the visible part of the displayed list instead of the whole list that needs to be resolved when field group occurrences must be displayed in normal fields.

This needs to be set up per desired linked field and can only be done in database tables which are empty. If the procedure is performed in a database table which has data, loss and corruption of data is the undesirable consequence. If the new linkref table structure is required for an existing database table with data, a bespoke migration procedure must accompany the setup to preserve and convert relevant data into the new table structures. Then please consult Axiell ALM for Help.

The new table structure can only be implemented for reversely linked fields (with or without metadata) and for hierarchically (internally) linked fields. (The relevant options are greyed out for other types of linked fields.)

Hierarchically (internally) linked fields

Only internal links of the Hierarchical type can get the new table structure, not the other types. In thesau.inf this would be the broader_term <-> term <-> narrower_term relationship only or part_of_reference <-> object_number <-> parts_reference in collect.inf, for example. Especially the latter is a good candidate because in archives this internal link is used for the entire hierarchy and records can often have many child records. Let's implement the new table structure for this internal link.

DSLinkrefTableProperties1

For internal links, the relevant Indexed link properties can be found on the Internal link properties tab of a selected internal link definition.

1. Make a backup of your SQL database and your Axiell application files, just in case something doesn't work out right. Also note you need a backup to go back to if you'd like to undo this new setup because the new settings and new table structure break compatibility with older versions of Designer and versions of Collections older than 1.11.
2. You cannot perform this procedure if the collect tables still have valuable data in them. A data migration procedure must take place before you can continue. Consult Axiell and do not proceed with step 3 and further.
3. Mark the Indexed link checkbox on the Internal link properties tab of the selected internal link definition.
Note that if the field group to which this field might belong also contains other reversely or hierarchically linked fields, then you are not allowed to mark the Indexed link checkbox for such fields too: only one linked field in a field group may be assigned the indexed link properties.
4. Of broader and narrower field occurrences, the new table structure no longer saves the occurrence numbers in which data was originally entered, so the preferred sort order must be set here. So select a Broader sort field and a Narrower sort field from the drop-downs. You can only pick from indexed fields in the same relevant field group. Also set the sort Order for both. For example:
 
DSLinkrefTableProperties2
5. Saves your changes to the .inf and recycle the application pool.
6. To create the new table structure for this internal link, just clear the collect tables from Designer by right-clicking collect and selecting Clear database in the pop-up menu. This will not only delete all data in the collect tables but will also recreate all required SQL tables, including the new one. The new table name has the format dbo.<table_name>_<tag1>_<tag2>_lrel, in this case dbo.collect_bt_nt_lrel. Below you can see the new table structure. Each row represents a single hierarchical link from both the parent as well as the child perspective. Column bt contains the record number of the linked parent record (from the child's perspective) while column nt contains the record number of the linked child record (from the parent's perspective). The meta column is redundant for this type of link so it will always contain 0. The bt_data column contains all (unresolved) data (formatted as record XML) of the parent (Part of) field group as registered in the child record, while the nt_data column contains all (unresolved) data of the child (Parts) field group as registered in the parent record. The prikey column finally, provides a primary key for each link registered in this table, which comes in handy for table replication which is desired by some customers to create copied identical tables for a publicly accessible AIS.
 
DSLinkrefTableProperties3
 
An example of bt_data of prikey 1 would be:
 
<record priref="0" creation="2021-03-25T13:45:59" modification="2021-03-25T13:45:59" selected="False">
    <field tag="B5" occ="1">We only recently found out the relation with the parent record</field>
    <field tag="1l" occ="1">2</field>
</record>
 
Note that the link reference also appears in the data itself.
An interesting consequence of the fact that this data is now stored in this new table, is that it won't be present in the normal record XML in the base collect table anymore, not even the parent or child link references. Of course, you won't notice any of this underlying structure as a user in Collections, apart from the fact that it increases performance.
Also interesting to note is that the index definitions for tags 1L and 1l still need to be present in collect.inf. but they won't have matching SQL tables anymore after you cleared the database: even reindexing these indexes from within Designer won't create the index tables but will just reindex the dbo.collect_bt_nt_lrel table instead (which can do no harm). So leave the relevant link reference index definitions be, otherwise you'll get Object reference not set to an instance of an object errors in Collections and users won't see any values in the Parts and Part of field groups anymore.

Reversely linked fields with or without metadata

Reversely linked fields (either internally linked or to a field in a different .inf) have new options on the Linked field properties tab, in the Indexed link properties box. Let's assume we have two reversely, internally linked fields in collect.inf: copied_to (cT with linkref tag Ct) and copied_from (cf with linkref tag cF).

1. Make a backup of your SQL database and your Axiell application files, just in case something doesn't work out right. Also note you need a backup to go back to if you'd like to undo this new setup because the new settings and new table structure break compatibility with older versions of Designer and versions of Collections older than 1.11.
2. You cannot perform this procedure if the collect tables still have valuable data in them. A data migration procedure must take place before you can continue. Consult Axiell and do not proceed with step 3 and further.
3. Mark the Indexed link checkbox on the Linked field properties tab of one of the reversely linked fields. Then automatically the checkbox will also get marked for the reversely linked field. (This works with deselecting the checkbox too.)
Note that if the field group to which this field might belong also contains other reversely or hierarchically linked fields, then you are not allowed to mark the Indexed link checkbox for such fields too: only one linked field in a field group may be assigned the indexed link properties.
4. When occurrences of the current linked field are displayed in a reversely linked record, Collections needs to know how to sort them because the new table structure no longer saves the occurrence numbers in which data was originally entered, so the preferred sort order must be set here. So select a Sort field from the drop-down and set the sort Order: do the same for the reversely linked field. You can only pick from indexed fields in the same relevant field group. For example:
 
DSLinkrefTableProperties4
5. Saves your changes to the .inf and recycle the application pool.
6. To create the new table structure for this internal link, just clear the collect tables from Designer by right-clicking collect and selecting Clear database in the pop-up menu. This will not only delete all data in the collect tables but will also recreate all required SQL tables, including the new one. The new table name has the format dbo.<table1_name>_<tag1>_<table2_name>_<tag2>, in this case dbo.collect_Ct_collect_cF. Below you can see the new table structure. Each row represents a single reverse link from both the perspective of both linked records. Column collect_cF contains the record number of the linked record registered in cf/cF while column collect_Ct contains the record number of the linked record registered in cT/Ct in the relevant records. The meta column will contain 0 if for this reverse link no metadata fields have been set up, while it will contain the primary reference of a metadata record (which is still stored in its own metadata table) if metadata fields for this reverse link have been set up indeed. The collect_cF_data column contains all (unresolved) data (formatted as record XML) of the linked field group as registered in the record where cF is filled, while the collect_Ct_data column contains all (unresolved) data of the linked field group as registered in the record where Ct is filled. The prikey column finally, provides a primary key for each link registered in this table, which comes in handy for table replication which is desired by some customers to create copied identical tables for a publicly accessible AIS.
 
DSLinkrefTableProperties5
 
An example of collect_Ct_data would be:
 
<record priref="0" creation="2021-03-04T12:12:23" modification="2021-03-04T12:12:23" selected="False">
   <field tag="Ct" occ="1">200000003</field>
   <field tag="5Q" occ="1">4</field>
</record>
 
while an example of collect_cF_data would be:
 
<record priref="0" creation="2021-03-04T12:12:23" modification="2021-03-04T12:12:23" selected="False">
   <field tag="cF" occ="1">200000002</field>
   <field tag="3Q" occ="1">4</field>
</record>
 
Note that the link reference also appears in the data itself, as well as the primary reference of the metadata record (stored in tags 5Q and 3Q respectively, in this example).
An interesting consequence of the fact that this data is now stored in this new table, is that it won't be present in the normal record XML in the base collect table anymore, not even the link references of the reversely linked records. Of course, you won't notice any of this underlying structure as a user in Collections, apart from the fact that it increases performance.
Also interesting to note is that the index definitions for tags Ct and cF still need to be present in collect.inf. but they won't have matching SQL tables anymore after you cleared the database: even reindexing these indexes from within Designer won't create the index tables but will just reindex the dbo.collect_Ct_collect_cF table instead (which can do no harm). So leave the relevant link reference index definitions be, otherwise you'll get Object reference not set to an instance of an object errors in Collections and users won't see any values in the reversely linked fields anymore.
 
A similar example of a reverse relation (without metadata) between collect (loan.in.number, with link reference tag lK) and loans (object-in.object_number, with link reference tag lL) will result in a collect_lK_loans_lL SQL table for example (either database name could be mentioned first). An example of a single registered link in this table would look as follows:
 
DSLinkrefTableProperties6

2021-03-05: new Media type tag property for image and application fields

From Designer 7.7.3, image and application fields have a new property: Media type tag on the Image properties and Application field properties tab respectively.

DSMediaTypeTagProperty

Previous to Collections 1.11, linked video and audio files displayed broken-link icons in front of records in the Result set and Gallery views (although the files displayed or played fine in the Media Viewer), if no proper thumbnails could be generated, as is the case for audio and video files, or documents for example.
From Collections 1.11 though, if properly set up and if media types are registered together with media references in the records, then for file identifiers without file extension (which could occur when media files are retrieved via the WebAPI or a DAMS), instead of broken-link icons, the following generic icons will display for audio, documents, images and video files. These icons will also be displayed without proper setup or registered media types if the media type can be distilled from the file name extension while still no proper thumbnail can be generated.
ACaudioIconACdocumentIconACimageIconACvideoIcon

So if the registered media files in your application all have a file extension, like .jpg, .doc, .mp3 or .pdf for example, you don't need to change anything to the setup of your image and application fields: Collections 1.11 will automatically notice and recognize the file extension and if it can't create a proper thumbnail image, one of the above icons will be displayed in the Result set and Gallery views instead.

If, on the other hand, most or all of the registered media files in your application do not have a file extension, because they are identifiers for files retrieved from a DAMS, for example, and you would like the above generic icons to be displayed instead of no icon (!) at all when no thumbnails can be generated, then you will need to do some set up, as follows:

1. You will need to create new, repeatable text field per image or application field in every database for which you like the new generic icons to appear. This field will later contain so-called MIME types (to indicate the media file type) like audio/mpeg or image/jpeg. Make the field length 100. The field needs to be put in the same field group as the relevant image or application field. It doesn't need to be indexed.
2. For image and application fields linking to the media database, the new field needs to be added as a write-back field to the linked image or application field so that the MIME type gets written back to the media record too. So the media database needs to get a media/MIMY type field too.
3. Enter the new field tag (or look it up by clicking the ellipsis button next to the property box) in the Media type tag property of the associated image or application field. You'll have entered an existing (allowed) tag if it is being replaced by its field name automatically as soon as you leave the property.
4. It's not required that the field is present on a screen as well, but recommended nonetheless. So put your new fields close to their associated image or applications fields, so that they can repeat together. Make it a writable screen field. Label it Media type or MIME type, as desired.
5. Repeat the above steps for all desired image or application fields.
6. Save your changes and recycle the Collections application pool.

The new setup will make sure that whenever a media file is now uploaded to one of these image or application fields in a record in edit mode, the relevant MIME type will be entered in the Media type field automatically: Collections will extract that type from the file extension or from the file itself if it has no extension. The user won't need to touch that value and Collections will use it to display the proper generic media type icon when appropriate but also to prepare the Media Viewer for the proper media type.
The reason for the media type screen field being writable is that if the above setup has been applied to fields in a database which already has data in it, the user must be allowed to enter the appropriate MIME types in this field manually, if desired. (If all MIME types are the same for a particular field, one could use the Collections Search and replace function for a record selection, to enter that MIME type for a lot of records all at once.) Note that a MIME type registered in the media type field will take precedence over any actual file name extension (if present), when Collections determines which media type icon to display.

Valid MIME types can be found on the internet. Common ones can be found here, for example: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types

By the way, an actual thumbnail of an image file of which the MIME type can be determined, will only be generated by Collections if it is one of the HTML5 image types (GIF, PNG, JPEG or SVG). Of other file types, no thumbnail can be generated.

Further note that for one or two customers a <MediaTypeTag> element was introduced and implemented earlier (but never documented) in their settings.xml to do the same thing as the new Media type tag field property, but that setting is now deprecated (because it doesn't work in all situations) and should be replaced by using the new field property.

Using this setting will break compatibility with older versions of Designer and Collections versions older than 1.11.

2021-03-05: a substituting Original filename tag property for image and application fields

From Designer 7.7.3, image and application fields have a new property: Original filename tag on the Image properties and Application field properties tab respectively.  

DSMediaTypeTagProperty

The option replaces the <OriginalFileNameTag> element in the settings.xml configuration file for Collections. It has the same functionality but that older way (see chapter 4.7 in the installation guide for Collections) of matching image and application field tags to field tags which should hold the original file name when the actually linked media file is turned into a GUID, is now deprecated. The settings.xml way will still work if you don't use the Original filename tag property for fields, but if you consider using the new property, then use if for all fields that were configured in settings.xml for this purpose and then remove the section from settings.xml (although the field properties will take precedence over the relevant settings.xml section if you left it there accidentally).
So if a part of that section is the following, for example:
 

  <DatabaseName ="collect">

    <FieldTag ="FN">

      <OriginalFileNameTag>SO</OriginalFileNameTag>

    </Field>

  </Database>

You would replace it by looking up the FN field tag in collect.inf in the Designer Application browser and on its Image properties tab you would simply enter tag SO (or look it up by clicking the ellipsis button next to the property box) in the Original filename tag property. You'll have entered an existing (allowed) tag if it is being replaced by its field name automatically as soon as you leave the property.

Using this setting will break compatibility with older versions of Designer and Collections versions older than 1.11.

2021-03-02: new &1 execution codes 30 and 29

From Collections 1.11, storage and edit procedures set up for a reversely linked database are now executed when either:

the current main record is saved, after a new link is established between this record and a record in the linked database (before edit procedure, followed by storage procedure before storage);
the current main record is saved, after the value in a write-back field for a new or existing link to a record in the linked database has been changed (only the storage procedure before storage)
the current main record is saved, after an existing link between the current main record and a record in the linked database has been removed (before edit procedure, followed by storage procedure before storage)
the current main record is saved, after the current main record with an existing link to a record in the linked database is deleted (before edit procedure, followed by storage procedure before storage)

When the edit procedure for a reversely linked database is executed because of one of the reasons above, &1 will be 30.
When the storage procedure for a reversely linked databse is executed because of one of the reasons above, &1 will be 29.

The new execution codes allow you to build code into an edit or storage adapl (use the latest ADAPL compiler that is issued along with Designer 7.7.3) which is only executed when the record is updated through a reverse link. If you don't need that but you just want the existing code (which might currently still only be executed if &1 = 11) to be executed as well when the record is updated through a reverse link, then you'll have to change conditions like if (&1 = 11) to if (&1 = 11 or &1 = 29).

2021-02-26: Copy record and Record template methods added

By default, the Copy record and Record template functions have always been available in all data sources and there was no way to hide these functions.

ACCopyRecordIcon ACRecordTemplatesIcon

From Designer 7.7.3.1538 though, a Copy record method type and a Record template method type are now available for methods in data sources, allowing you to set limiting access rights for certain roles, to hide the function in certain data sources for certain users if desired. If you just add one or both of these methods to data sources, without assigning access rights, then those methods will be available in these data sources to everyone.
From Collections 1.11, the Copy record and/or Record template functions will only be present in the Record details context toolbar if a method of the new Copy record and/or Record template type respectively have been added to the relevant data source. This means that to maintain the current Copy record and Record template functions in all data sources, these methods will have to be added explicitly to all those data sources! You don't need to assign access rights to them if everybody is allowed access to the functions. So if these methods have not been added to a data source when Collections 1.11 is going to be used, then both functions will no longer be present in that data source.
To hide the function for all users in all data sources, you won't need to do anything: the missing methods will hide both functions by default in Collections 1.11 an up.

Adding these methods will break compatibility with older versions of Designer and Collections, but removing the methods will restore that compatibility.

2021-02-25: Enumerative fields can no longer accidentally be made multilingual anymore

Enumerative fields should never be multilingual, because of the nature of the field. However, previously you could still accidentally mark the 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.

2021-02-10: release Axiell Designer 7.7.2.955

Today we release Axiell Designer 7.7.2 (build 7.7.2.955), offering the bug fixes and new functionality described below. Axiell Designer can be downloaded from Hornbill: see the FAQs section.

Bug report no.

Short problem description

AX-196

Partially created metadata link references caused the database to become unviewable in Designer.
Now if you have a partially defined metadata reference, you will receive a warning when you open the database definition in Designer.

AX-194
CV1-2437
CV1-2694

Metadata tables were not properly populated on reindexing: relationships from occurrences above 1 in repeated field groups were missing. This bug also caused metadata triple index tables to corrupt.

Also, if the two link reference tags involved in a metadata table setup were identical, then the two relevant record numbers after creating a metadata record ended up in the tag of the wrong database, the metadata record was mirrored as it were. This bug also caused metadata triple index tables to corrupt if both involved field tags for such a table were identical. (Note that metadata tables have only been implemented in very few custom applications.) If metadata triple index tables are indeed part of your database configuration and there exist metadata tables with identical tags (like dbo.disposalPb_m_organisation_da_peoplePb_linkTable for example, in which Pb is the identical tag), then the tables with identical tags have to be fixed.

To fix the second corruption, do the following:

- In SQL Server Management Studio, "clear" a relevant table (when no-one is working in Collections and do make a backup first) by executing a SQL command similar to the following (replace data source name and table name by the appropriate ones):

DELETE

 FROM [MY-DATASOURCE].[dbo].[dbo.disposalPb_m_organisation_da_peoplePb_linkTable]

Do this for all relevant tables.

- Then use Axiell Designer 7.7.2.955 or higher and reindex one of the link reference indexes related to the relevant link (in the example above that would be the index on tag Pb): note that the reindex runs twice (it says “Completed” twice), so don’t close the Reindexing window too quickly.
 
- Install Collections 1.10.2 to prevent the second bug from appearing again

The first corruption can only appear if you've ever reindexed metadata triple indexes manually from within Designer. In that case you'll have to clear all metadata triple indexes and reindex them using Designer 7.7.2.955.

2020-10-13: field inheritance now enforced for entire field group

For data integrity reasons it is required that once you set a data dictionary field to Inheritable (on the Field properties tab), the same setting should be made for all fields in the same field group, except that for linked fields in the same field group only the link reference field should be set that way too (not for the linked field itself nor any merged-in fields). To enforce that requirement and to help you do it right, you are now prompted when you mark or deselect the checkbox.

ACInheritancePrompt

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).

2021-01-07: Allowing non-media file downloads from an image field linked to a DAMS

An Axiell DAMS may store different so-called renditions of a media file uploaded through an image field, like a thumbnail, an original-size image and/or images or movies in different formats. When Collections retrieves such a file for display or download via de WebAPI, the DAMS will provide the file in the proper format because the Retrieval path and Thumbnail retrieval paths for the image specify the rendition to retrieve via the getcontent server parameter which points to the relevant image server configuration for the DAMS.
However, when non-media files are uploaded through an image field, it is stored in the DAMS as is, and when Collections must later retrieve the file for download (because the Collections user clicked the download button next to the image field), the DAMS normally tries to apply the rendition for detail images (using the rendition specified in the Retrieval path), which is impossible in this case and thus obstructs the download and returns an XML error.

From Axiell Designer 7.7.2.764 (and the Axiell WebApi 3.0.20350.1), image fields therefore have a new option: Download path, underneath the Thumbnail retrieval path. This optional setting allows you to provide a third rendition-specific call to the WebAPI with the server parameter pointing to a different rendition configuration specific for downloading the file as is. Such a rendition configuration will have to be added to the DAMS configuration manually.

Further remarks:

PDFs cannot be viewed in the Collections Media Viewer, but they can be viewed in the browser after clicking the download button next to the image field.
Although the Download path option is present for application fields as well, it has no function for those fields.
For backwards compatibility, if no Download path has been entered, the Retrieval path will be used instead (but that may generate an error for non-media files).
Setting the Download path option breaks compatibility with Collections 1.10.0 and Designer 7.7.1 and older versions. Emptying the option restores that compatibility.

2020-10-13: making a linked field validable on more than one field

Normally a linked field has a lookup field which has a single index. The production.place field in collect.inf in a 4.5.2 application for example, links to the term field in thesau.inf, for which there is a single index, with the fixed domain GEOKEYW (geokeyword). So if a user enters a partial or complete term in the production.place field in an object record, Collections will check that value against all terms with the GEOKEYW domain in the thesaurus, to establish whether the value already exists or not.
Term records in authority database tables like the thesaurus often have another field (besides the term field and the domain field) to identify the term further (as terms needn't be unique), namely the term.code field. A lot of users would like to use terms and term codes intermingled in the same field: if they know the term code by heart they would like to enter that value and have Collections show the auto-complete drop-down list for the linked field with relevant term/term code combinations as they type the code and automatically replace it by the appropriate term, while if they only know the term, they would like to enter the term and validate it against the auto-complete drop-down list or the Find data for the field window normally. Examples of such desired validation combinations are subject classification code/subject term, Dewey classification code/subject term and geographical place code/place name. So the production.place field could be a field that would profit from such double validation.

From Designer 7.7.2.760 and Collections 1.10.1 this functionality is available, but must be set up per desired linked field manually. It takes the following changes:

1. In the authority database, create a combined index on the fields that you'd like the user to be able to validate on, in our example that would be the term (tag te) and term.code (tag tc) fields. Assuming both fields already have an index, you'll first have to create a dummy field in the authority database definition, thesau.inf in our example, to create the combined index for. For example:
 
DoubleValidation1
 
DoubleValidation2
2. In the desired catalogue field linking to the authority table, you must now change the lookup field to the new temporary field. This will cause Collections to use the combined index for this field from now on when the user tries to validate a term or term code. In our example we would change the Lookup field for production.place to term_plus_code_index_field.
 
DoubleValidation3
3. The last (optional) thing to do is add a format string in the new Selection list format string option which can also be found on the Linked field properties tab. This format string specifies how the validation fields are displayed in the auto-complete drop-down list for this linked field. In the example above we entered %te% (%tc%), meaning that the term will be shown, followed by the term code in between brackets. In this case, if no term code is present, the brackets will still show without anything in between. You can enter field tags enclosed in % and fixed text and spaces. The format string is optional: if you leave it out, the auto-complete list will just use the forward reference field to look up and show terms.
Note that backwards compatibility is broken as soon as the Selection list format string option for a linked field has been filled in, but can be restored by emptying the option again.

Here's how it works in Collections. As soon as you put the cursor in the (Production) Place field, the auto-complete list opens with all available terms (with any term codes in brackets) for this field.

ACDoubleValidation1

You can pick one directly by clicking it or start typing either the term or the term code, after which the list only shows the matching term/term code combinations.

ACDoubleValidation2

ACDoubleValidation5

Click the desired term/term code combination to copy it to the field.

ACDoubleValidation3

After leaving the field though, the term/term code combination is automatically replaced by only the term. In the record, only the record number (link reference) of this linked record will be stored: the term and term code are only retrieved for display.

ACDoubleValidation4

Instead of using the auto-complete drop-down list, you may also click the validate icon on the right side of the field to open the Find data for the field window. On the View hierarchy tab you'll also see the term/term code combinations and you can filter the list by typing either (the beginning of) a term or term code.

ACDoubleValidation6

2020-11-11: using adapl-only output formats for PDF and plain text printouts

From Designer 7.7.1.690 and Collections 1.10 you can implement adapl-only output formats to generate output as a plain text file (which can also be a .csv file, because that is plain text too) or as a PDF file: by "adapl-only" we mean that the output format only needs an adapl with PRINT and OUTPUT statements to generate plain text output and optionally PDEST <file_name.extension> FILE to specify the file name and extension/mime type (so you do not combine the adapl with a Word template or XSLT stylesheet in this case).
If the provided file name extension is .csv, it will return a plain text file with mime type text/csv, while if the extension is .txt the mime type will text/plain. If you leave out a PDEST command altogether or include it but leave out the FILE, parameter, then the generated output will automatically be converted to a PDF. In the PDEST command you only need to provide the file name with the extension, but it's no problem if the file name is preceded by a path (which might be the case in an existing adapl output format): the path will be ignored anyway.
Collections will stream the generated file to the user, after which he or she can open or save it at will.

When setting up this type of output format you must set the Template type to the new Custom option, which is introduced for adapl-only output formats specifically. Using this setting will break compatibility will older versions of Designer and Collections, but you can restore compatibility by removing the output format or changing Custom to something else.

AdaplOnlyPrinting

You can even add a Parameters screen to this output format, if you want to collect some user input which the adapl must use.

(Former) Adlib for Windows application managers may know that their application (whether it's now being run in Collections or still in Adlib) already contains a number of adapl-only output formats. To activate them for use in Collections only(!) you would need to set their Template type to Custom, but you would still need to check the adapl for Collections-incompatible commands like INPUT, LOCATE and DISPLAY (no extensive list of non-compatible commands is available at this point). User input can now be obtained from a parameters screen, so this will require some reprogramming. You may want to check any PDEST statement in relevant .ada file to see if it generates the required file type. If you want the output format to be available in both Adlib for Windows and Collections, then just make a copy of the existing output format, set it to Custom and adjust it further if required. The copy will be visible in Collections only while the original (which doesn't need adjusting) will only be present in Adlib.

2020-11-11: image and application fields path properties now available in field list grid view

When you click the Fields header in an .inf, the right window pane fills with a grid view of all fields. The displayed columns in this view can be selected via the Column chooser (right-click a column header and select Column chooser in the pop-up menu). Three new columns are now available: Storage path, Retrieval path and Thumbnail retrieval path.

ColumnChooser

2020-11-09: yesno ADAPL function now supported

In Collections, the YESNO ADAPL function previously did not present a confirmation dialog and always assumed the answer would be yes (true), because that was the more likely response. From Collections 1.10 the user will see a confirmation dialog though. The user has about nine seconds to choose between the Yes button (true) and the No button (false). The seconds are counted down in the No button, indicating that if no choice is made, the result will be as if the user clicked the No button and the message will close by itself. Although Yes normally is the more likely answer, No would usually be the safest option because if this function appears in adapls, clicking the No button often means that the procedure or action won't be executed. So the default (after waiting nine seconds) is now the opposite of what it was.

ACYesNoMessage

The confirmation message works in at least before-edit, after-field and before-storage adapls, but not in output format adapls. A complete list of supported adapl types is not available at this moment.

2020-10-29: release Axiell Designer 7.7.1.658

Today we release Axiell Designer 7.7.1 (build 7.7.1.658), offering the bug fixes and new functionality described below.

Bug report no.

Short problem description

AX-176

The Application browser didn't recognize or load a specific adlib.pbk file.

AX-168

Object incompatibility on import if the Disable Download property was enabled for a field: import error '0', info: ' 172 (object newer version): Unknown object 12, last known object = 39.'

AX-9

The application tester did not report nor correct merged-in field definitions that had the wrong multilingual setting.

2020-10-13: link screen adapl supported in Collections 1.10

Any set up Link screen adapl meant to filter out records from the View table tab in the Find data for the field window for a linked field in Collections, is supported from Collections version 1.10. The adapl also works on the auto-complete drop-down list for a linked field. Note that the functionality may slow down performance when opening the Find data for the field window.

2020-10-05: using the Destination dataset field property

On the Linked field properties tab of a linked field you can find the Destination dataset field property. The property is used for linked fields which link to an entire database table or a large dataset, while the user should be able to pick a (smaller) dataset when creating a new linked record from within the Find data for the field window. In that case, the property is usually filled with an enumerative field containing a list of data sources in which the new linked record can be created. See the documentation.title field (tag ti) in collect.inf in a 4.5.2 application for example, using the dataset.document (FE) field in the same .inf as the enumerative list. This used to work for Adlib but not for Collections. Collections offered no choice of dataset and just wrote the new linked record in the first available dataset.
From Collections 1.10 (or unreleased 1.9.6.2189) though, Collections does offer the user a choice of data sources in which he or she is allowed to create the linked record. Collections does use the field set up in the Destination dataset field property for this purpose, but not in the old way. The only requirement for the field is that it is a text field of sufficient length to contain the data source names and that it is repeatable, so it does no longer need to be enumerative and if it still is it doesn't do anything with the translations in the specified list. It is just used by Collections as a temporary container for the user-selected data source: a temporary container is required since Accept link (previously labeled Create term) is a delayed linked record creation. The list will dynamically be filled with the names of the data sources in which the user is allowed to create new records and the data source names will be retrieved from the .pbk. The field will not be stored in the record xml. So for existing applications, nothing needs to change: the enumerative lists might not serve their original purpose anymore, but you can leave them as is. Only for new linked fields which use a new destination dataset field, you now know what the requirements for that field are.

2020-09-24: numeric field properties

Collections 1.10 displays all previously stored numerical values with maximally ten decimals by default, in both edit and display mode, without any automatic padding with trailing zeros. So by default the behaviour has remained the same.

However, you can now change this behaviour in Designer 7.7.1.636 or higher: you can see that all numerical fields (in the .inf files) now have two new properties on a new Numeric field properties tab: Number of decimals (with a default value of 10) and Pad with zeros (deselected by default), matching the behaviour in Collections. You can change these options per field. Mark the Pad with zeros checkbox if you want Collections to add trailing zeros for display or other retrieval (like export or print) of a numerical value in this field. Or change the Number of decimal places to some other value if you don't want users to enter more decimals than that from then on.

NumericFieldProperties

For example, with Number of decimal places set to 2 and Pad with zeros marked, if you were to enter a value like 3.1 and leave the field, the displayed value will become 3.10 (although it will still be saved as 3.1, but you can only see that in the properties of the field in Collections). If previously stored numerical values contain more decimals than set in the Number of decimal places option, editing and saving the record won't change those values even if you had put the cursor in such a field without changing anything. So in this example, a pre-existing value like 3.1234 would be displayed as 3.12 but still exist as 3.1234 in the edited or stored record. The actually stored value in a numerical field can be found by right-clicking the field and selecting Properties in the pop-up menu. In this example, a previously stored numerical value with more than two decimals would only be stored differently, namely with maximally two decimals, if you actually change the value yourself. You'll see that you can still type a value with more decimals, but as soon as you leave the field, the value will be rounded off to the set number of decimal places and will be stored that way too.

With either a marked or a deselected Pad with zeros setting, it's no use typing any trailing zeros yourself to indicate the level of specificity or accuracy (of a measurment for example) because they will be stripped off when you leave the field. Use the Pad with zeros option instead and set the Number of decimal places to the expected level of accuracy.

Note that changing one of these options breaks compatibility of this .inf file with Collections 1.9.5 or older and Designer versions older than 7.7.1.636. Although every numerical field now shows these defaults, they are implicit defaults (so they're not yet stored in the .inf) as long as you don't change either option and save the .inf. Just saving the .inf because of some other change won't include the defaults and thus won't break backwards compatibility.

2020-08-19: release Axiell Designer 7.7.1.486

Today we release Axiell Designer 7.7.1 (build 7.7.1.486), offering the bug fixes and new functionality described below.

Bug report no.

Short problem description

AX-152
AX-150

Language values (translations) for enumerative fields were cleared after clearing all databases, running an import and clearing all databases again but also after changing the database Server name in a specific .inf.
Fixed in 7.7.1.316.

AX-149

Designer kept prompting to save a specific, unchanged adlib.pbk file.

AX-147

The Record lock manager was no longer included as a stand-alone tool, although it could still be opened from within Designer.

AX-138

An import into a Finnish_Swedish_CI_AI collated database, could skip records because of false duplicate key errors (error 91) in uniquely indexed fields, for characters that only differed in their diacritical character, which are actually different letters in these languages.

AX-137

Clearing a specific database would clear all databases of which the name started with the same word.

AX-135

An update import job would add default values to empty fields (for which default values had been set up) in existing records, but that should never happen in existing records.

AX-133

When, after creating a new import job, the list of import jobs in the Import jobs manager was sorted on modification date, an error Object reference not set to an instance of an object error was generated.

AX-128

After exporting a record without owner (tag OW), the resulting file would often still contain the name of the user who did the exporting, as the owner.

AX-127

Running a certain import job would corrupt the .inf file.

AX-124

When starting designer on a clean Windows Server 2019, it gave a warning the first time it was started, that the publisher was unknown.

AX-120

Designer 7.7.0.4439 would crash on startup.
Fixed in 7.7.1.47.

AX-113

Screen label justification properties in the XML documentation were missing or incorrect.

AX-107

Using Designer as an administrator, a user would get error 189 or 369 when trying to update the part_of_reference (bt) field in an Archive Catalogue record during import.

AX-101

It was not possible to copy a task definition to another data source.

AX-86

Designer 7.7.19311.1 could not save a .pbk file anymore after making certain changes to an enumerative field in a task field list.

AX-82

Import jobs did not respect membership of Active Directory for access to records during import.

AX-81

When reindexing all indexes or all word indexes, the wordlist table in the SQL database was deleted but not created again.

AX-72

An unhandled exception error occurred when adding a SQL server name to .inf files, if one of the .inf files had a ~ in its name.

AX-66

The XML documentation for solitary label elements contained incorrect position info.

AX-65

The XML documentation for field label elements contained incorrect position info.

AX-64

The XML documentation for screen elements contained incorrect info on position and size for the Box, Image, and Text window elements.

AX-63

Multiple screen Webbrowser control properties were missing from the XML documentation.

AX-62

Multiple screen HTML field properties were missing from the XML documentation.

AX-61

Multiple screen field properties were missing from the XML documentation.

AX-60

Multiple screen label properties were missing from the XML documentation.

AX-59

Multiple screen box properties were missing from the XML documentation.

AX-58

Multiple screen properties were missing from the XML documentation.

AX-57

Screen XML documentation didn't list all <screen-field> elements in the correct order of their top-left display position.

AX-47

An import job would fail when the target .inf contained a geojson field.

AX-46

The application test function did not detect a linked field mapping using it's linkref as a destination field in the field mapping.

AX-42

A specific import job returned an error 169: object type unknown.

AX-36

A record type access configuration was not copied along when copying a field definition.

AX-31

In Application tester warnings like WARNING: No link reference defined for linked field 'bt' (part_of), the Application tester didn't report the relevant database, so you didn't know where to look for the mentioned linked field.

AX-28

PageSize could not be selected as a column for the Index list view.

AX-26

The Application tester reported (for some fields only) the existence of a language tag for language English. This related to an obsolete CBF implementation of multilingual fields, which is no longer relevant.

AX-25

It was impossible to copy a data source containing tasks or connections.

AX-23

The Fields column in the Index list view was no longer present.

Disable download of images

Mark the Disable download checkbox on the Image properties tab of an image field to make it impossible for Collections users to download any media file linked in this field. The media can still be viewed in the Collections Media Viewer and thumbnails will still be displayed in the Result set view, but a download button next to the image field will be hidden.
Note that it is not enough to set this option for the reference_number field in media.inf, you'll also have to set it for all image fields linking to that field, like the reproduction.reference field in collect.inf, etc.

DisableDownload

Errorm messages in different colours

The errorm statement in adapls may be used for different types of messages, just to inform the user, to warn the user or to alert the user about an error. From Axiell Designer version 7.7.1.170, command-line adapl compiler 7.6.20125.1 and Axiell Collections version 1.8.1.794, it is possible to show these messages in their own colour: blue for informative messages, orange for warnings and red for errors.

DifferentErrorColours

To this end the ADAPL errorm statement has been extended with a severity option. Depending on the severity level the message is shown in a different color:

errorm 'INFORMATION in blue', 0
errorm 'WARNING in orange', 1
errorm 'ERROR in red', 2

Note that there are no brackets around the arguments behind the errorm statement.

When the severity code is not set, it defaults to an (orange) warning, for backward compatibility. (Previously though, an errorm message would be red if the current &E result code from some FACS operation was non-zero while it would be green at all other times.)

When the error severity (value 2) is set, this has consequences for:

Before storage adapl procedures: the record can’t be saved if such an error occurs.
Before edit adapl procedures: the record doesn’t go into edit mode if such an error occurs.
Field adapl procedures: the code after the errorm is not executed any further.

The information and warning severities (values 0 and 1) have no such consequences.
Errorm's with severity codes can also be used in task adapls, screen adapls and field adapls.

Note that Collections also still generates green messages, to indicate that an action was successful, when a record has been saved correctly for example.

A formatting option for integer fields

Prior to Collections 1.8, integer fields were by default displayed as formatted with thousands separators, but this was not always the desired behaviour and it was also not consistent with the Windows client, which just displays the integer value as is. In the Library catalogue, for example, the Search year (sj) field is defined as an integer with length 4 and is meant to contain just year values. Having the year 2018 displayed as "2,018" (or 2.018, depending on the client's Windows locale) was undesirable.

In 1.8 this was fixed. By default, integer fields now display their value without thousands separators. Here in Designer, a Presentation format option was added below the Data type setting on the Field properties tab of data dictionary fields, to allow you to still have integer fields displaying thousands separators. By default the option is set to No formatting, but you can set it to Use selected language to get the old behaviour back. This is a per-field setting.

Having adapl-created documents uploaded to a repository via Collections

When creating a new Word document via the ADAPL Wordcreatedocument function, you may provide the file name and possibly a relative path in front of it. Typically, the adapl will then insert that (path\) file name in an application field. For Adlib for Windows, the storage and retrieval path for that field would typically be some base path, so Adlib would concatenate this base path and the field contents. In Collections however, a hard-coded relative path and file name may conflict with a DAMS or image server storage URL and (a different) retrieval URL, because application fields are also open for uploading files manually by the user (turning the file names into GUIDs), bypassing the adapl, in which all uploaded files must end up in the same target folder/repository. In that case, Collections would normally not be able to write documents created by an adapl (and filled in in the application field) to the repository.
To solve this problem, an (optional) fourth option has been added to the Wordcreatedocument function, for which you must specify the field tag of the relevant application field (without quotes around it). Instead of hard-coding the tag you may also use tag indirection, so if you've stored some field tag ax in a text variable called my_tag, then !my_tag could be used instead of ax.

If the adapl needs to write a document in a sub folder of the storage path, then make sure that the repository already contains that sub folder, because Collections can't upload those files to a sub folder if it doesn't exist yet. Also note that a relative path to such a sub folder should not be preceded by ../ or ..\ because that would conflict with the storage and retrieval URLs and also pose a potential security risk.

Example:

result = WordCreateDocument (template_path + templatename, docname, 1, !docreftag)

The new option is supported by the adapl compiler in Axiell Designer from version 7.6.18347.1.

Prompted output formats for Axiell Collections

Designer 7.7 and Collections 1.7.3 and higher support so-called prompted output formats. These are normal, predefined output formats that, after selecting one, first present an entry form (a parameters screen) to the user, allowing him or her to enter some extra details pertaining to the print job, before actually printing. These details may just be some extra information to be printed (like a user name or date or reason for printing) or some data with which the output format must still do something (although that data cannot be used to filter out some of the marked records from printing).

The entry form is a normal screen with field tags (parameters) that pertain to the output format only, not to any database definition (.inf). This parameters screen must be specified in the Parameters screen option on the Output job properties tab of the output format.
The relevant field tags must also be defined underneath the relevant output format: you may copy existing tags from some .inf or create new tags, but they won't interfere with any field definition in an .inf. You may create new fields for the output format by right-clicking the output format (or the Fields header underneath it, if already present) and selecting New > Field in the pop-up menu. The requirements for these fields are the same as for tasks: linked fields still need a linked database and a link reference field and you will have to define their Linked field mapping (merged-in) destination fields in the field list as well. Fill out or check the appropriate parameter properties as you would for database fields.

In a Word template, the data entered by the user on the entry form can be printed by including normal references to the fields from the parameters screen but precede each field tag by PARAMETERS+, <<PARAMETERS+a1>> for example if a1 is one of the parameters. PARAMETERS could be considered the name of the implicit FACS buffer that will hold the field contents entered by the user on the parameters screen.

An output format doesn't need to consist of just a Word template though, you may combine a Word template with an adapl too, if you want the adapl to do some preprocessing of data. In the adapl you can access the data entered in the parameters screen by creating a FACS declaration named PARAMETERS (always use this name). There's no need to OPEN this FACS declaration since it is not a real database: after this declaration we can just use the FACS parameter aliases as if they were normal FACS field tag aliases.

Example:

fdstart PARAMETERS ''
a1 is user_name
a2 is print_date
a3 is print_reason
a4 is selection_description
fdend

For an elaborate example of creating a prompted output format, click here.

New ADAPL function: GUID

Syntax

value = guid()

Arguments

value: text

Meaning

The GUID function generates a 16 byte (128 bit) globally unique identifier, that could be used as a persistent ID for a record for example. A GUID is a pseudo random number which is supposed to be unique in the world. Although not a 100% guaranteed unique, the total number of unique keys is so large that the odds of a certain GUID being created twice is very, very small. An example of a GUID would be: 963d5dab-2d6e-4bd8-9f71-6245ba795a50

See also

Linked open data and Persistent ID's

 

Importing data into a database with None default access rights

If the Default access rights property of the database has been set to None or Read you can still import records into this database, using Axiell Designer or import.exe, but you cannot import records that link hierarchically or reversely to an existing record or have imported records force new linked records automatically, because for the latter actions the access rights mechanism of the application becomes active and since Designer and import.exe have no knowledge of user names and roles specified in the application, the $REST role is assumed instead of the proper role of the user who is doing the import (who should have at least write access).

To allow for a successful import in such circumstances anyway, the role entered in the Record owner option of an import job will now also be the role with which the import job will be carried out by Designer 7.7.19345.2 or import.exe 7.619345.3 and higher versions. So you should now use an import job Record owner with Full or Write access to the relevant database. If you don't want this record owner to end up in the Owner field in imported records too, you can still use an import job Storage adapl to empty the Owner field again.