Sunday, 23 January 2022

Sonraw (2)

Nearly a year ago, I wrote about the external procedure SONRAW and how it changes values in the linked PARTARC table. I've just made an important discovery about this table after having run SONRAW.

Let's say that there is a part P0 that is the 'grandfather'; P1 will be both a son of P0 and a father, and R1 is a purchase part that is a son of P1. Assuming that there are no more sons in the BOMs of P0 and P1, and that SONRAW is 'fed' part P0, after SONRAW is run, there will be two rows in the linked PARTARC table. In both rows, PARTARC.PART will be P0; in the first row, PARTARC.SON will be P1 and in the second row, PARTARC.SON will be R1. So far, nothing new.

What I have just discovered is that in the first row, PARTARC.SONPARTREV will be P0 (not very useful), but in the second row, PARTARC.SONPARTREV will be P1! This means that the direct father of any purchase part can be found in the linked PARTARC table, something that I thought was not possible. This is even better if there is a phantom between P1 and R1, because looking at the unlinked PARTARC of P1 will show the phantom. Also, there's no real way of getting the parent of R1 - until now!

Not surprisingly, this is very important for a report that I am trying to write; the original version obtained the purchase parts, which is fine, but now I need to get some values from the direct father.

[Edit from 03/10/22: After SONRAW, PARTARC.SONQUANT also contains the internal number of the direct father, although again, this is a real number so one has to write PART.PART = ROUND (PARTARC.SONQUANT).]

Wednesday, 19 January 2022

:HTMLFNCTITLE

The documentation about this variable is as follows: The report title can be changed at runtime in the SQLI step preceding the report step, using the :HTMLFNCTITLE variable. When would one need/desire to use this variable? When one wants the title of a report to contain the value of a variable; for example, 'List of orders entered on 18/01/22' could be achieved by the following means

:PAR1 = DTOA (SQL.DATE8 - 24:00, 'DD/MM/YY'); SELECT ENTMESSAGE ('$', 'P', 10) INTO :HTMLFNCTITLE FROM DUMMY;
where message 10 would be 'List of orders entered on <P1>'  (I use this method to get Hebrew strings into a program - it's easier this way than writing naked strings in the program text that get reversed ... or not). As the documentation states, the above should be in an SQL statement prior to the report whose title one is creating.

This technique is especially useful in 'HTML documents', especially here. But should one does use this technique when there are more reports to be displayed after the one whose title is to be changed, then one must insert another SQLI stage after the given report to nullify the value of :HTMLFNCTITLE.

One might be tempted to use :HTMLFNCTITLE in an 'ordinary' procedure consisting of an SQLI step to collate/calculate data, followed by a CHOOSE step then a few reports, where one will be activated according to the value of the CHOOSE step. Don't get me wrong: the technique will still work, provided one inserts an SQLI step before the desired report. 

So where's the pitfall? 'Ordinary' reports created without :HTMLFNCTITLE display their title (this may come from the report's title - which is limited in length - or from the sub-form 'output title) along with the parameters used to create the report. I find this information very useful when debugging reports that other users have created (e.g. answering the question why a given order doesn't appear in a report - because the parameters of the report don't match those of the order).  This information does not appear in a report whose title has been changed by :HTMLFNCTITLE.

So: it's ok to use :HTMLFNCTITLE in an 'HTML document' but not advisable to use it in an ordinary multi-step report.