Update Adlib to Axiell Collections

In order to run Axiell Collections on an existing Adlib application (4.5.1 or older), it is necessary to make the Adlib application Collections-ready.

Axiell Collections runs on Model Applications 4.5.2 and up, or on older application versions that have been customized for compatibility with Axiell Collections. Customizing an old Adlib application for compatibility with Axiell Collections is complex and can be risky if you do not have sufficient experience with application management.

Note: If you have a Model Application that has not been customized and you have a maintenance contract with Axiell, you are entitled to an upgrade to the current application version. This entitlement is forfeit once you start changing your application.

If you have a local Adlib installation, please also be aware that you may not be able to run Axiell Collections locally, so please consult with our Sales department before you start changing your application.

If an existing Adlib application (4.5.1 or older) has to be updated for Collections compatibility, the following steps must followed. While you may be able to do this yourself, it is highly recommended that Axiell performs these steps.

To make the Adlib application Collections-ready:

  1. Create a backup of your Adlib files and SQL database!

    Backup all your Adlib files and SQL database before changing your application or database structures.

  2. Run the application tester tool found within Designer

    Check the application for issues that should be corrected by selecting Tools>Application tester in Axiell Designer.

  3. Axiell Collections is less forgiving of database structure imperfections than Adlib for Windows so make sure your Adlib application and database structure are in good shape by running the ValidateDatabase tool. The tool checks one or more Adlib databases for any field tags that have not been defined in the data dictionary (your .inf database structure files), reports on them and adds generic field definitions for those tags to the relevant .infs.

    Notes:

    • The tool only works on SQL databases.
    • Contact Axiell Support for access to the latest version of the ValidateDatabase tool; read the ValidateDatabase chapter in the Database integrity tools guide here and run the tool for all your databases: use the fix option to add any missing generic field definitions.

    Tip: Another good way to test the data for issues is to run a full re-index on all the databases within the application. Any issues (such as incorrect ISO date formats, etc.) will appear in the log in the main Axiell Designer window.

  4. The move to Axiell Collections provides a good opportunity to clean up your data. Our Helpdesk can provide a number of tools to help with this process. For the best results, use the tools in the following order:

    #

    Tool

    Details

    1.

    RemoveTagsFromData

    When the ValidateDatabase tool is run you may find new provisional fields in your .infs. These might be fields that you actively use, and therefore should be kept (screen fields that were never registered in the .inf, for example). However, others may contain garbage data (which could have entered your records accidentally during an import or an adapl procedure, for example) and you will probably want to remove these tags and their data.

    The RemoveTagsFromData tool is designed to remove tags and their content from your records in one or more Adlib SQL databases.

    Note: For more information, download the Database integrity tools guide here and refer to the RemoveTagsFromDatabase chapter.

    After removing a tag from a database, remove the relevant provisional field definition from the .inf manually since it no longer serves a purpose.

    2.

    IndexCheck

    Command line tool designed to check whether indexes in your databases are correct by reading all records again and comparing the current contents of the index to what is supposed to be indexed. If wrong keys appear in the current index, or if values from records are still missing, IndexCheck can automatically perform repairs to yield a correct index.

    Refer to the IndexCheck chapter in the Database integrity tools guide for more information about this tool.

    3.

    LinkRefCheck

    Command line tool designed to ensure that the reference in the link reference tag of Linked fieldsClosed A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). in your SQL database points to an existing linked record and that no value is stored in the Linked field itself. It also empties any accidentally stored merged-in fields because merged-in fields should not be stored in the database either.

    Refer to the LinkRefCheck chapter in the Database integrity tools guide for more details.

  5. Run ConvertInternalLinks (old applications)

    Tool designed to convert the structure and contents of fields internally linked on value (as was the case in Adlib model applications older than version 4.5.2a) in one or more tables in your Adlib SQL database to fields internally linked on reference. If you have an Adlib application 4.5.2a or higher, skip this step as your internally linked fields are already linked on reference.

  6. Adapl-only output formats are supported from Collections 1.10. They only become visible in Collections once the Template type option for these output formats has been set to Custom.

    Collections does not support Word template output formats with the .dot and .dotx extension. The good news is that Collections does support Word templates with the .docx extension, it supports output formats that have been specified as a combination of an adapl and a .docx template, and it also supports XSLT style sheets as output formats. Incidentally, the .docx format is also supported by Adlib for Windows 7.5 or higher.

    Word templates must be converted to the .docx format in order to be used in Axiell Collections. Although this must be done manually, it is not difficult or time consuming, and does not require changing the references to your Word templates in your application structure (.pbk): Collections automatically looks for .docx templates with the same name as the .dot(x) templates already set up as output formats.

    See Creating output formats for Collections for details about converting Word templates and how to get the new standard Word templates.

    In the Transport / Despatch, Incoming loans and Outgoing loans data sources there are a number of Template checkboxes that, once clicked, generate a Word document and store it on the server (a request or freight letter for example) in the selected language, after which the path to the created document is automatically registered in the Digital document field:

    This is handled by two after-field adapls: loanproc.ada/bin and tranproc.ada/bin. The adapls use the wordcreatedocument function and the yesno function. Instead of the old .dot templates, the wordcreatedocument function should now address .docx templates, while the yesno function does not work in Collections and always returns 1 (as if the user replied Yes to the question). The adapls need to be adapted and all called templates need to be converted to the .docx format before these checkboxes can be used in Axiell Collections.

    If you are using a model application 4.5.1, running on Adlib for Windows 7.5 or higher or in Axiell Collections, you can download the new model templates and adapls here and move the adapls from the zip file to your Adlib \adapls folder and move the templates to your Worddoc\templates folder. However, if any of these templates have been modified (by adding your institution name or logo or by altering the fixed texts), you are probably better off using the adapls from the zip file but converting your templates yourself:

    • condition#.dot
    • condition-in#.dot
    • condition-objin#.dot
    • contract#.dot
    • despatch#.dot
    • entry#.dot
    • ownerrequest#.dot
    • renewal#.dot
    • renewal-out#.dot
    • request#.dot
    • request-out#.dot
    • reviewrequest#.dot

    Converting these templates usually only requires opening them in Word and saving them under the same name but as a .docx file.

    Users of older applications could adjust their loanproc.ada/bin and tranproc.ada/bin themselves, given the following information. Do not simply copy the code however: check how far it applies to your application and change what needs to be changed.

    Aspects of loanproc.ada/bin 4.5.1 and tranproc.ada/bin 4.5.1 that have changed:

    • The following variables have been added to the variables declaration:

      text templatename[50]

      text strippedtime[6], fulltime[8]
      integer templatenamelength

    • The extension .doc was removed from the string docname = '...' everywhere in the code. For example:

      docname = '_request.doc'

      has become

      docname = '_request'

    • Sub routines 500 and 501 in loanproc.ada were changed to:
      500 /* Create Word document
        templatename = enumval$ (!templatetag[occ], !templatetag, -1)
        if (right$(templatename,3) = 'dot') {
          templatenamelength = (len(templatename) - 3)
          templatename = left$(templatename, templatenamelength) + ~
                         'docx'
        }
        if (right$(templatename,4) = 'dotx') {
          templatenamelength = (len(templatename) - 4)
          templatename = left$(templatename, templatenamelength) + ~
                         'docx'
        }
        result = WordCreateDocument (template_path + templatename, !docreftag[occ], 1)
        if (result <> 0) {
          errorm 'Error creating Word document ' + ~
                 !docreftag[occ] + '; code = ' + result
          !docreftag[occ] = ''
        } else {
          !docdatetag[occ] = date$(8)
        }
      return

      501 /* Create Word document reference: document_path + 
          /* loan number + docname + date + time (without colons)
          /* + .doc

        fulltime = time$(1)
        strippedtime = left$(fulltime,2) + ~ 
                       mid$(fulltime,4,2) + right$(fulltime,2)
        !docreftag[occ] = document_path + !numbertag + ~
        docname + '_' + date$(8) + '_' + strippedtime + '.doc'
        return
    • Sub routine 500 in tranproc.ada was changed to:
      500 /* Create Word document
        fulltime = time$(1)
        strippedtime = left$(fulltime,2) + ~ 
                       mid$(fulltime,4,2) + right$(fulltime,2)
        !docreftag[occ] = destination_path + !numbertag + ~
        docname + '_' + date$(8) + '_' + strippedtime + '.doc'
        templatename = enumval$ (!templatetag[occ], !templatetag, -1)
        if (right$(templatename,3) = 'dot') {
          templatenamelength = (len(templatename) - 3)
          templatename = left$(templatename, templatenamelength) + ~
                         'docx'
        }
        if (right$(templatename,4) = 'dotx') {
          templatenamelength = (len(templatename) - 4)
          templatename = left$(templatename, templatenamelength) + ~
                         'docx'
        }
        result = WordCreateDocument (template_path + templatename, !docreftag[occ], 1)
        if (result <> 0) {
          errorm 'Error creating Word document ' + ~
                 !docreftag[occ] + '; code = ' + result
          !docreftag[occ] = ''
        } 
      return

    For the relevant fields, the yesno function in loanproc.ada can present the following questions to users in Adlib for Windows, while in Collections they are skipped and assumed confirmed:

    1. Do you want to add the objects (excl. refused/withdrawn) to the exhibition record?
    2. Do you want to create a Despatch record for these objects (excl. refused/withdrawn)?
    3. Do you want to create an entry record for these objects (excl. refused/withdrawn)?
    4. This Word document has been created before. Do you still want to create a new document?

    The changes in sub routines 500 and 501 address the fourth question: to prevent earlier created Word documents from being overwritten by default in Axiell Collections. The sub routine does overwrite the contents of the field but the document it creates gets a unique name so that the old document is not overwritten.

    For the relevant field, the yesno function in tranproc.ada can present the following question to users in Adlib for Windows, while in Collections it is skipped and assumed confirmed:

    • Do you want to update the current location for the linked objects with the location you have entered here? Note: If you have not entered a date and/or time here, the current date/time will be used.

  7. Unlike the Change locations procedure in Adlib for Windows, Axiell Collections uses a customizable setup, and if you want this functionality in Collections, it is necessary to set it up first. We have done some of that work for you. The setup needs to be done with Adlib Designer 7.5 or higher, which means that you will have to update your Adlib for Windows executables to that version as well if you continue using Adlib for Windows.

    Refer to Add the Change locations procedure for more information.

  8. Axiell Collections offers new (optional) functionality, including Geographical maps functionality, a Related records View and Bulk insert option. As it is highly customizable, it must be set up first in order to be available to your users.

    Refer to the relevant Application configuration options for more information.