Release notes for wwwopac.ashx 3.7.14042

The question mark wild card character for word indexes

From wwwopac.ashx version 3.7.14042, a question mark can be used a single-character wild card for searches in word (free text) indexed fields. For example: searching for the string 'm?n' would find words like 'man', 'men', 'mcn', etc., but not 'moon' or 'meaning'. Using '?' as a single-character wild card was already functional for term indexes, but not for word indexes yet.

Larger-than and smaller-than searching in enumerative fields

From wwwopac.ashx 3.7.14041, larger-than and smaller-than searching in enumerative fields, using > (alphabetic succession), >= (alphabetic succession or equal to), < (alphabetic precedence) or <= (alphabetic precedence or equal to), works as follows:

  1. First, wwwopac determines whether your search key is one of the defined neutral values in the enumerative field or one of the English "translations" (other display languages not supported yet). This can be determined by the WebAPI before the search is executed because the neutral values and their translations of the field have been set in the database .inf file.
  2. a. If the search key is a neutral value (the indexed enumerative value actually stored in records), the actual search will be performed on the neutral values corresponding to the used logical expression. So if you'd have an enumerative list with neutral values BOR, AAB, ZET and ELF, and you would search on >=ELF, wwwopac would search the index of the enumerative field on the values ELF and ZET.
    b. If the search key is an English display value, as you could see when you viewed an appropriate record in Axiell Collections with the interface language switched to English, wwwopac would determine its associated neutral value using the .inf and then perform the actual search on the neutral values corresponding to the used logical expression. So if you'd have an enumerative list with neutral values BOR, AAB, ZET and ELF with the respective English display values Super, Fine, Mediocre, Bad, and you would search on <=fine, wwwopac would search the index of the enumerative field on the value AAB alone, not on any of the other values (because in alphabetical sense there exist no enumerative values for this field which precede AAB. So in this case you wouldn't find records displaying the enumerative field value Bad. Note that the order of values in the list (or their meaning) is irrelevant to this functionality.
    Further, in wwwopac.ashx version 3.7.14038, searching an enumerative field on everything but the search key, using <>, has been fixed: previously, an = search was performed instead of a <> search. The logic of an unequal-search is similar to that of a larger-than or smaller-than search.

'today-nn' and 'today+nn' functionality fixed

Issues with searching on today's date minus or plus an integer number of days, using the 'today-nn' or 'today+nn' syntax, have been fixed in wwwopac.ashx 3.7.14041. A partial example of its use: search=input.date>'today-100', to search on records entered into the database in the past hundred days.

Searching on non-existing saved search (aka pointer file)

From wwwopac.ashx 3.7.14037, searching on a non-existing saved search will generate an Adlib.Query.Exeptions.PointerFileDoesNotExistException instead of just returning zero records. ("Profiling" a non-existing saved search would already give an exception.)

Searching a non-indexed enumerative field

From wwwopac.ashx 3.7.14036, searching a non-indexed enumerative field will generate an error message informing you that you are trying to search a non-indexed enumerative field like you were searching a normal text field. Previously, a general null pointer exception would be generated.

Pre-6.4 data structures are no longer supported

From wwwopac.ashx 3.7.14032, database structures processed by adlwin.exe versions older than 6.4 are no longer supported. This means that the domain column needs to be present in thesaurus index tables; in older versions, the domain and term were separated by a double colon in the same column. If you have an old data structure and wish to use wwwopac.ashx 3.7.14032 or higher, your database structures need to be converted. Please contact the Axiell Helpdesk for more information about this upgrade procedure.

Internal link relationships linked on value are no longer supported

From wwwopac.ashx 3.7.14032, internal links need to have been linked on link reference (priref). This is the case by default in model applications 4.2 and higher. Older applications usually have internal links linked on value. If you have an old data structure and wish to use wwwopac.ashx 3.7.14032 or higher, your database structures and application need to be converted. Please contact the Axiell Helpdesk for more information about this upgrade procedure.

Binary columns no longer supported

Binary columns in SQL tables are no longer supported from wwwopac.ashx 3.7.14032: therefore the record data must be stored in XML format. This also means that SQL Server 2000 is no longer supported. If you have a SQL database with binary columns and wish to use wwwopac.ashx 3.7.14032 or higher, your database needs to be converted. Please contact the Axiell Helpdesk for more information about this conversion.

Field names in adlibweb.xml now validated

From wwwopac.ashx 3.7.14028, field names specified in the briefFields, detailFields, searchFields and authenticationConfiguration sections of adlibweb.xml will be validated to the requirements for XML element names on application start. If a field name doesn’t meet the requirements, the WebAPI will throw an exception (AdlibWebException) with details about the field name, section and the database. If you encounter the exception after your upgrade to wwwopac.ashx 3.7.14028, you’ll have to correct the problematic field names in the data dictionary (.inf file) and subsequently in adlibweb.xml. Changing the English translation of a field name may have consequences for XSLT stylesheets and any Word templates in which the old field name is used: you’ll have to apply the changes in there as well.
The XML element name requirements are as follows: names may contain letters, numbers and other characters but they cannot start with a number or punctuation character or with the string ‘xml’. And names are not allowed to contain spaces.