Re: _cipher API vs Qc3Encrypt/Qc3DecryptData vs SQL

It's true they are different, but I think your main problem in convincing us is that you have a much lower-level view of how it all works than most of us.

For example, I don't see how an application program would necessarily be aware of the result. In an earlier email, it was suggested to simply rename the PF, then name the VIEW as the original name of the PF, and the application program wouldn't know the difference, as long as the format of data in the buffer passed to the application program isn't changed. However, it is true that with a VIEW vs a change-capable READ trigger, it /could/ know the difference, by reading the same field from the PF and from the VIEW and comparing them. I think I'm agreeing with you that in the OPs given scenario, a VIEW would work as well as a READ trigger.

Speaking of low-level views, it is also true (afaik) that no application program currently has the ability to see the "actual" data in a PF record that contains a date, time or timestamp field; they only see what some low-level routine provides. This could be seen as analogy of how a READ trigger would affect things. Which is to ask, why are you so concerned that the actual data in the file would no longer be visible if a change-capable READ trigger were available? If it is /properly/ implementing the business rules of the company, what's the problem? Granted that you've shown situations where it could be poorly implemented and leave gaping holes, it's also true that possible poor implementations should not be an argument against a particular tool.

*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /


CRPence wrote:

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