Sunday, 4 June 2023

COC document (2)

As Maslow's hammer puts it, when the only tool you have is a hammer, every problem looks like a nail.

This happens to me every now and then in Priority, when I choose a complicated solution involving procedures when there exists a simpler method. For example, someone wanted me to send him copies of delivery notes when the status of those notes is changed to 'final'. I wrote something similar to this for the same person, sending a letter when the status of a customer order changes. This involved writing a procedure that sends an email, that is invoked by a trigger. Complicated. I was about to write the same sort of procedure for the delivery notes when I remembered that I could define a simple rule that would fire when a delivery note reaches a given status: it can send email with an attached document. Request solved after a few minutes of thought and one minute of development. As it happens, a few days later, the person making this request asked me to stop sending the documents!

So, again, with the COC document. I couldn't figure out how to have the HTML document work on devices when the imput is customer orders, so I wrote a procedure that would obtain the devices from the order then invoke the HTML document with this list of devices. I was looking at the documentation again when this statement caught my eye:

HTMLCURSOR (Create HTML Document) — Declares the cursor for a document. This step first creates a linked file that holds the records selected in the PAR input parameter.

If the PAR input parameter contains orders, then the internal cursor will obtain an order number from this linked table, but what is important is the value selected in the query - this value will be stored in the internal variable HTMLVALUE and will be a device number.

My original code in the external procedure was as follows

LINK ORDERS TO :$.ORD; ERRMSG 1 WHERE :RETVAL <= 0; LINK SERNUMBERS TO :$.SER; ERRMSG 1 WHERE :RETVAL <= 0; INSERT INTO SERNUMBERS (SERN, SERNUM) SELECT ORIG.SERN, ORIG.SERNUM FROM ORDERS, ORDERITEMS, SERNUMBERS ORIG WHERE ORDERS.ORD = ORDERITEMS.ORD AND ORDERITEMS.ORDI = ORIG.TEST_ORDI AND ORIG.SERN > 0 AND ORDERS.ORD > 0; EXECUTE WINHTML '-d', 'TEST_WWWCOC', 'SERNUMBERS', :$.SER, '-e'; UNLINK ORDERS; UNLINK SERNUMBERS;

My new code in the HTMLCURSOR stage became
SELECT SERNUMBERS.SERN FROM ORDERS, ORDERITEMS, SERNUMBERS WHERE ORDERS.ORD = ORDERITEMS.ORD AND ORDERITEMS.ORDI = SERNUMBERS.TEST_ORDI AND SERNUMBERS.SERN > 0 AND ORDERS.ORD > 0;
ORDERS is automatically linked to the PAR parameter, so this code provides a list of all the devices linked to the lines in the given list of orders. A much simpler solution than my baroque construction!

I wonder now what I had written in this statement in the first version of the document that receives an order number.