See also our Customisation Support Policy.

Caliach Vision V5: Full Site Support - Coordinated Customisation

Introduction: V5 and Site Customisation

Our experience of migrations to V5 have led us to streamline the handling of site customisation. We have already added a feature to the Upgrade Via the Internet that can both upgrade Caliach Vision system code with fixes and enhancements and site customisation (from a site secure folder on our FTP server) simultaneously.

Why Customisation can be Problematic

Experience has shown with customisation on migration to V5 that a number of issues can cause problems, delays and increased costs, best summarised as the following:

  1. All your customisation should reside inside your ProgCode.usa (or ProgUser.db with V5). Over time, different users can create different ProgCode.usa files and the "latest" may just contain the "latest additions", so the full suite of customisation is not complete. Custom classes can lurk in the Vision.lbs you are using. This problem can lead to the loss of custom reports, etc. on migration, and then extra days of work to re-build them.
  2. The naming convention for custom reports and other classes can be inconsistent and may be unsafe as V5 has several new class name prefixes.
  3. With customisation managed locally by you on the site, any request to us to add or modify stuff requires the latest to be sent to us even when we already have the latest because we can't be sure you haven't changed something.
  4. Because V5 customisation is technically more complex than V4.1 and earlier, local tinkering can have unpredictable results and then the need for help is expensive when we have to provide it remotely. Inevitably moving to a client-server SQL architecture means having a reasonable knowledge of the SQL language and a deeper familiarity with Omnis Studio syntax and variable system.
  5. Site system managers leave, or are replaced, or memories fade so it is common that there is no full knowledge on-site of what part of the customisation does what.
  6. When major upgrades take place changes can effect previously stable customisation leading to downtime and "fear" of upgrade.
  7. Technically V5 is more prone to customisation obsolescence than previous versions. This is because reports have to be "passed" the data (using parameters) rather than just read it directly. The link between program core and custom reports is more intimate and therefore vulnerable to changes in the core programme. If we know what sites have as customisation, we can fix issues without the site even knowing there was a problem, rather than you suddenly and inexplicably finding out something is broken. For instance, we could speed up standard reports by restricting the columns of data returned from the server to those needed on the standard report. That would break your custom report that had a couple of added non-standard columns.

Full Site Support Service

We now have long experience of independently wholly managing and maintaining one site's extensive customisation. Despite the scale, this site still has ultimate "ownership" of the customisation, but does not have to discriminate between the core program or their customisation when seeking help from us with issues. We treat it as a full site and identify what falls into customisation and additionally charge for the work on that part alone. It is a seamless, worry-free service.

The way V5 Full-Site Support works is as follows:

  1. We manage and maintain your customisation, and hold it in your private FTP folder on our server. This allows changes to be included in Upgrade Via the Internet.
  2. When you ask us for anything we have an installation dedicated to your site to quickly establish what is needed and implement it. Charges are minimised and will be invoiced subsequently.
  3. If you want to implement changes yourself, you will need to notify us so that we can upgrade our master set-up accordingly, at a small charge.
  4. Setting up existing V5 migrations is free, and for new migrations where we have converted customisation it would start as the default at no additional cost. New sites, electing to have Full-Site Support after doing their own customisation would be charged a small set-up fee depending on the extent of it. A copy of your database would also be needed to complete the Full-Site Support set up.
  5. The most important advantage of Full Site Support would be when faults are fixed or enhancements made we would be able to identify quickly that a site customisation was affected by it and seamlessly apply to it a change at minimum cost, so you can rest assured that any system upgrade will not affect your customisation. Economies of scale and automation will enhance this.
  6. One barrier to Major Upgrades is the fear of upsetting site customisation that often limits or delays enhancements that would otherwise be useful to you. If we have access to all customisation we would be able to identify who would be affected and work around the issue. The new V5 client-server architecture makes this more likely to occur than previously. If sites were Full Site Support both enhancement-fear by us and fear-of-upgrade by you would be, if not eliminated, significantly reduced.

This Full Site Support should improve your experience of Caliach Vision and confidence in your customisation. It may not suit every site but, by default, we will assume that you will want to use this service. If you don't want it you will need to opt out.

In practise, Full Site Support will mean:

  1. Your site customisation will be held on our FTP server and available to Update Via the Internet.
  2. We will routinely maintain it in line with Caliach Vision maintenance when it needs it. You will be charged for this on the basis of Customisation Support Policy and invoiced occasionally when this happens. This may sound like a Direct Debit license but it is not. Think of it as a holistic approach to trouble-free customisation integration with Caliach Vision maintenance.
  3. To manage this, when we perform a Full Site Support Service, we will raise a Sales Order which would stay on our system indefinitely and add a line item for each customisation encounter, making a dispatch and invoice you when it was worth it (sometimes just once a year, but more often more frequently.). It would be completely transparent.
  4. Our desire here is to improve our ability to enhance the product with maximum take-up and minimum disruption. To do that we need to have some central management of site customisation.
  5. You can opt out and go-it-alone if you wish, and bear the risk of getting out of sync with Caliach Vision's core.

Upgrade to V5 Customisation Rewrite

Typically, a client site has a collection of Custom Reports and/or Features that over the years they have accumulated, some written by Caliach and others that may have been written or amended by amateurs. They are in the form of classes, which can be thought of as internal files containing the layout and operational program that allows it to function inside Caliach Vision. This set of classes are collectively held in a ProgCode.usa file. (note the paragraph 1 at the very top of this page).

There is no known mechanism for the automatic conversion of pre-V5 classes to V5 standards, so for a client to retain Caliach Vision site customisation when upgrading to V5 the custom classes have to be rewritten from scratch, usually starting with a copy of a standard V5 report (windows are more complex). As explained in the foregoing, V5 is a much more complex environment than earlier versions, so this is not a job for inexperienced amateurs, even when you are just tinkering. Experience tells us the demand for support becomes unreasonable, so we do not encourage it, as we did in the past.

This is a paid-by-the-hour service from Caliach Ltd. under Full Site Support

The way we do a rewrite for V5 is as follows:

  1. First we look at what you send us, which should be:
    • For each datafile set you use, operate File -- System Manager -- System Timing Test, then Print Report to Acrobat PDF. Send us this document.
    • Send us your latest ProgCode.usa file that is located in the same folder as your datafile set.
    • Go to File -- System Manager -- Privileges and Settings, then choose the System tab pane. Click on the bottom left Backup to Text File button, name it in a convenient location and then send us this file.
    • Let us know that you only use the datafile sets in 1 above. Some businesses hold old backups that occasionaly they refer to for historical reasons. If this is the case with you, we need to know in advance so that we can plan to also upgrade these data sets.
  2. We look at this material and assess as best we can whether it is complete. If it looks complete, we can start work by setting up a site installation on our equipment that will include your datafile set for test migration of your data.
  3. If your customisation contains database structure customisation (e.g decimal point precision, text length limits, etc) , at this stage we must write the code classes that will replicate these changes in the migrated database, otherwise data loss may result.
  4. We will then test migrate your data so we have a database that we can test our rewrite classes against. Up to this point we have spent a couple of days on the job.
  5. We now start the rewrite proper, class by class, and this can be a tedious, painstaking and laborious process. For each class we have to:
    • Examine the old class to determine which V5 master class it is best derived from, or a variant of (e.g. a custom SO will start as a renamed duplicate of "rSalesOrder").
    • The name will invariably change along with the $version and $desc property values.
    • The test database System settings will have to be changed to reflect the new class name.
    • We then have to visually compare, in design windows, the New and Old class and where the old class differs from the standard, implement the difference in the new class. This is a lot more difficult than it sounds. For a start not all modifications that were done are visual or obvious at first glance. We try our best to pick up what is special to you, but ultimately you are the best judge, so it's pointless spending your money "chasing shadows"!
    • We then check that it works. If it is a report we will recognize little from your data and often this is significant.
    • It is important to understand what we do NOT do: We DO NOT compare the result with the original running on an old version using your old customisation. This would be incredibly time consuming and cost you a fortune! At any rate, we are not the best at spotting what amendments are needed, not least because we are not familiar with your data or why you got the original customisation done for, in the first place.
  6. At this point in the process we will publish (to you) the new customisation ProgUser.db, typically with an email with attached report V5Upgrade2Stage1<siteshortname>.pdf in which there is a section titled "Sub-stage 4 – Customisation Rebuild for V5". That will list the settings changes you must make so you can test the customisation yourself. Each report class typically takes 2 working hours or more, depending on it's complexity, to go through this process - we do not aim to deliver a perfect match of the old design first off - this is the start of an iterative process which inevitably requires cooperation.
  7. YOU now need to check each customisation report, window or combination. and if something is not perfect in your eyes, you need to email with a change request. In that, make sure you name the class correctly and explain the problem in understandable English. If it is a report, print it out, mark it up with a legible hand, and send a scan of that to us at
  8. Hint! if you want to appear intelligent don't use annotations like "bigger" or "smaller" but use "+1pt" or "-2pt". We work in centimeters, so "2 left" should be "2.000 left, etc. If you want to change or add text, put the text in the email so we can copy and paste rather than retype. Just remember at all times, if you make it easy for us, you will ultimately pay less.