An important change in version 24 regarding the status log of orders

I have written many procedures and reports that look at an order's status log; all these procedures look at the ORDSTATUSLOG table. A client wrote to me a few days ago and told me that one of these procedures (that is run automatically by the TTS) had stopped working. I checked this table and saw that the last entry was almost one month ago, but that changes in order status were still being reported. My unofficial conclusion was that I should no longer reference the ORDSTATUSLOG table but rather TODOLIST.

This table holds data from many different tables, so accessing the required data is slightly more complicated than what used to be. Here is an example of the queries that I used to write in order to obtain all the orders that were approved 'yesterday'

SELECT ORDERS.ORDNAME
FROM ORDERS, ORDSTATUSLOG
WHERE ORDERS.ORD = ORDSTATUSLOG.ORD
AND ORDSTATUSLOG.ORDSTATUS = -2
AND ORDSTATUSLOG.UDATE BETWEEN SQL.DATE8 - 24:00 AND SQL.DATE8 -1
...

This now becomes

SELECT ORDERS.ORDNAME
FROM ORDERS, TODOLIST
WHERE ORDERS.ORD = TODOLIST.IV
AND TODOLIST.TYPE = 'O'
AND TODOLIST.DOCSTATUS = 135
AND TODOLIST..UDATE BETWEEN SQL.DATE8 - 24:00 AND SQL.DATE8 -1
...

In belated recognition, the client sent me an extract from the Version 24 release notes that sort-of documented this change: they note that there will be no new tuples in ORDSTATUSLOG but don't say where the log will continue to be maintained, presumably because status changes had always been logged in TODOLIST.

Version 23.1 - Problem with private procedures to print purchase orders

We have upgraded to version 23.1 and have run into a problem with private procedures to print purchase orders. Such procedures do not print the totals part of an order. Preparing such a procedure brings up an almost impossible to understand error.

The actual problem is that new parameters have been added to report WWWPORD_3 that prints the totals. All one has to do to correct this annoying error is to add the new parameters as shown below. I've marked the new parameters in yellow.

There is a similar change to report WWWIV_3 that prints totals of invoices; the same new three parameters appear there and so have to be added to all private procedures for printing invoices.

Naming private variables in form triggers

Another problem when trying to upgrade to version 23: an error occurred when trying to add a line to a customer order. As this is an extremely common operation, it was of course very important to solve this problem. The error message said something about variable REF in a certain private trigger; had this variable appeared in the trigger then my life would have been easier.

I was reduced to removing all the private triggers from both ORDERS and ORDERITEMS forms: at this stage rebuilding the forms naturally was without problem. I added the triggers back one by one then rebuilt the forms each time until I received the confusing error. I had to do this several times (and of course, remove all the triggers) until I finally found the source of the problem: a trigger included a buffer, and in this buffer I had defined a variable REF. Renaming the variable to TEST_REF solved the problem. Obviously some standard trigger in ORDERITEMS also referenced the REF variable but as a different type.

As always, finding the source of a problem takes a very long time, whereas the fix is normally done in a minute or two.

What can one learn from this? In form triggers, always append the company's four letter prefix to all the variables defined in the trigger, even though these triggers are private. In modern programming terminology, a form and all its triggers constitute one namespace, and so variables must be unique. Employing the company's prefix will ensure that a future predefined variable will not clash with a user-defined variable.

Field names/titles in tables - revisited

My company is trying to update our Priority version from 21.1 to 23.1 and we've had several problems that prevented the update. One problem that can be fixed in advance is that if one adds fields to tables like GENERALLOAD and STACK*, then the title of the field should be the same as the name of the field (or at least, should have the four letter prefix). In other words, if I add a field TEST_INT11 to STACK4,  then the title of this field should also be TEST_INT11.

A previous blog discussed the same problem, but the real cause of the problem wasn't identified there.

Private table interface errors when upgrading to version 23.0

My company is currently in the process of checking the upgrade path to version 23.0; I have come across a problem with some private table interface errors. To be clear, a private interface does not use GENERALLOAD or a filename that is defined in the interface; this type of interface expects a file in the system/load directory whose name is the same as the interface, normally without extension.

In one interface, I defined a table variable DEBIT to be a character value of length 1. The upgrade error report says that this variable is an incompatible data type. I understand this to mean that I have reused a predefined variable name and instead of using the predefined data type - presumably int - I am redefining it as a character. This results in a page full of errors in the upgrade error report. The fix, of course, is simple - change the variable name to DEBITXX, or similar; of course, the code that inserts the data into the load table must also be changed.

In another interface, the same type of error occurs with a variable named DUEDATE (but not with a variable named QUANT). Again, the fix is simple.

Your experience, of course, may differ.