Wednesday 31 August 2022

A clever way of deleting a report

Credit where credit is due: this is not my idea, but it's brilliant. The scenario is that a report has been created but now has to be deleted. Normally I would go through the fields in the report, deleting them one after the other. This normally isn't problematic; the problems arise primarily when a report based on a standard report has to be deleted, as there may be translations of various fields' captions.

Someone suggested creating an upgrade where the type of event is DELENT. I very rarely work with upgrades as I nearly always develop on the target machine, but one of my clients uses it all the time. As it happens, I copied a report then discovered that the original report showed the fields that I wanted (or more accurately, didn't show the fields that I didn't want), so the copy was extraneous and could be deleted. I did this in my usual manner, then read about this tip. 

The screen shot below shows my manual deletion of the report in the shape of an upgrade.

Basically all one needs to do to delete a report is to create a new upgrade, then in the sub-form instead of choosing lines as one normally does, one manually enters the event DELENT, then writes the name of the report to be deleted (TEKN_KIYUT_FAMZIVNT in this case) and the type of entity (R). Presumably one then runs the upgrade and the report gets deleted.

The original tip was about deleting a form, something that I very rarely need. In this case, the entity type would be F. This tip should also be useful in deleting an entire procedure - in this case, the entity type would be P.

Sunday 21 August 2022

An SQL tip for comparisons

I want to describe a technique that I found a few days ago ('necessity is the mother of invention'), but I don't really know how to title it. I had a procedure that found work orders, but only those connected to customer orders. This requires the condition SERIAL.ORDI > 0. Someone else wanted the same report, but for work orders that are not connected to customer orders, namely SERIAL.ORDI = 0. I know how to use a flag in order to change a condition, but this always assumes that the comparison operator (>, =) is the same - but it isn't in this case.

I found a solution, although I am fairly certain that there are other ways of doing this. Let's say that :$.FLG = 'Y' if the user wants only work orders connected to customer orders. My solution converts the comparison operator into BETWEEN in the following manner:

GOTO 1 WHERE :$.FLG = 'Y'; :FROM = 0; :TO = 0; GOTO 2; LABEL 1; :FROM = 1; :TO = 0; SELECT MAX (ORDI) INTO :TO FROM ORDERITEMS; LABEL 2; SELECT ....... WHERE SERIAL.ORDI BETWEEN :FROM AND :TO ....
When :$.FLG <> 'Y', the users wants only work orders not connected, so FROM and TO will be zero. Otherwise the values are 1 and max (ordi) - guaranteed to work. Had the request been for work orders that might be connected to a customer order, then FROM would have been redundant: it would be 0 in both cases.