The scenario: a part is copied from company A to company B, along with various fields, including the path to the part's picture. The picture has a special status in the table PARTEXTFILE: the value of the field EXTFILENUM will be -1.
In the procedure that has been running for the past few years, the path to the picture has been obtained correctly, but was being stored as a regular entry in company B. The person responsible for company B had never brought this subject to my attention until now. When I saw that the picture was being saved as a regular entry, I tried to overcome this by passing the value -1 in the appropriate tuple in GENERALLOAD. This did not work.
My next attempt was a typical hack: find the value of EXTFILENUM for the part in company B and update it to -1. This worked, but obviously was not the correct way of solving the problem. Fortunately sanity was restored when I asked myself how regular saving of the picture works in the form LOGPART. This is when I discovered that the path is stored in the form variable EXTFILENAME, and that the trigger BUF11 causes this value to be stored as a picture in PARTEXTFILE (below is the standard code).
/* Insert, Update and Delete EXTFILENAME */ GOTO 111 WHERE :$.EXTFILENAME = :$1.EXTFILENAME ; /* clean previous record */ DELETE FROM PARTEXTFILE WHERE PART = :$.PART AND EXTFILENUM = -1 ; GOTO 112 WHERE :$1.EXTFILENAME = ''; EXECUTE DELATTACH '-I', :$1.EXTFILENAME; LABEL 112 ; /* insert new attachment */ GOTO 111 WHERE :$.EXTFILENAME = ''; INSERT INTO PARTEXTFILE (PART, EXTFILENUM, EXTFILENAME) VALUES (:$.PART, -1, :$.EXTFILENAME) ; LABEL 111;
Note the use of the procedure DELATTACH: this can cause the actual file to be deleted if it is not referenced anywhere. Saving the file parth in PARTEXTFILE is done by an insertion, thus enabling the value -1 to be set; doing this via an interface doesn't work.
Now I save the file path as the equivalent to :$.EXTFILENAME in the same tuple as the part name before passing it to the interface. And this works.
