Re: _cipher API vs Qc3Encrypt/Qc3DecryptData vs SQL

The appearance, at the surface, may appear to be the /same/ where in fact they are different; and of course DSPPFM does not do logical I/O. The difference is that the program that does the READ is aware of the result, by its having requested to *operate against* the logical VIEW of the data. And the VIEW is aware of the result, because the encapsulated SELECT has defined the logic to make the massaged data happen. In those cases, there was no intermediary that could vitiate the logic of the VIEW.

For example:

CREATE TABLE QGPL.T (ENCRYPTED VARCHAR (40) FOR BIT DATA)
CREATE VIEW QGPL.TV AS
(SELECT case Is_Allowed()='1' then DECRYPT(ENCRYPTED) end
FROM QGPL.T )
CRTDUPOBJ T QGPL *FILE *SAME T2
CPYF QGPL/TV QGPL/T2 /* Same garbage as if CPYF of the
*PF* with a change capable read trigger. *This* however
was an explicit request to copy from the VIEW; copying
the *PF* without chg-capRT gives a good copy as below */
INSERT INTO QGPL.T2 SELECT * FROM QGPL.T /* will work as
long as there is no change-capable trigger causing
garbage-out, conditionally based on Is_Allowed() */

If how obviously different the above requests are [using a VIEW and CASE vs UDF], than a change-capable Read Trigger effecting similar, I think I will have no hope in convincing anyone.

I am not arguing that it would be impossible to deal with and properly code for every possible case of a change-capable Read Trigger [it is just software], only that the existence of such an animal as the extension of the existing Read Trigger is folly. The big flaw is assuming one could insert a change-capable Read Trigger [that actually changes the data received by the program] without validating and correcting all programs and query logic; that is pure fantasy.

Regards, Chuck