Appliance Update: texisScripts-8.0.2, texis-6.01.133...

Post Reply
User avatar
Kai
Site Admin
Posts: 1271
Joined: Tue Apr 25, 2000 1:27 pm

Appliance Update: texisScripts-8.0.2, texis-6.01.133...

Post by Kai »

Two appliance updates are now available: texisScripts-8.0.2 and texis-6.01.133... The texisScripts update contains the following fixes:

Fixed 'Report Abbreviated' links being improperly escaped

Errors in crawled XML files are now saved properly instead of being printed to the walk log

Fixed crawls repeatedly launching and hanging when refreshing some Base URLs

Avoid potential duplicate results from indexed Parametric Set queries (in conjunction with texis 6.01.1334615000 or later)

The texis-6.01.133... update contains several Parametric Set search improves, including the following:

A PDF with no docInfo could cause anytotx to ABEND with -M (Appliance/Webinator default flag)

"Wrong size from TXa2i_setbuf()" errors may occur when updating a Metamorph compound index with row(s) larger than 512KB. Corruption unlikely from update, but can also happen during index create -- without any error(s) reported, and with corruption. Affects Texis versions from 2011-12-03 through 2012-03-16.

A parametric SQL query of LIKEP ANDed with an OR clause, could return results that keyword-match the index -- but do *not* post-process-match -- when the OR clause is true. If no Metamorph index, all table rows were returned.

Parametric or infield queries, when the main text/keyword query requires post-processing (or is linear) and is a relevance-ranked query, may return rows that do not fully match the keyword query. Using a parametric query that ORs a relevance ranked keyword query with a clause that refers to $rank may cause an ABEND or SIGSEGV.

A file:// directory URL with many (~100,000+) files in it was sometimes silently truncating files past ~80,000 or so, with no error. Workaround is to increate Max Page Size.

An IN query in Parametric SQL was not utilizing an index (and thus could take some time), if the parameter was on its left-hand side (and hence table field was on the right).

A Parametric infield:setFld(...) query (where setFld is a Set type parametric field) was silently not matching if the infield query was linear/post-process (e.g. ANDed with a keyword or other query). May also have happened with setFld IN (...)

These updates are available through the Maintenance -> Check for Updates menu.
Post Reply