Re: _cipher API vs Qc3Encrypt/Qc3DecryptData vs SQL

The whole point is that the application *would not* be /aware/ of the actions by a change-capable Read Trigger. There would be programmed changes manifest against the physical rows of data, as presented to the program, rather than program-requested changes being manifest against the rows of data in the _requested_ logical presentation. Programs being unaware of what is done by the database [trigger] activity on the way *out* of the program is generally innocuous. But the same can not be said about a program being unaware of what was done to the row data on the way *in* to the program.

When the program is compiled against a VIEW or against the physical file that has been replaced by an abstraction as VIEW, then the program can remain unaware and continue working, because all of the work is done in/by the database before the program ever sees the massaged row. That assumes the design of the abstraction was a proper _replacement_ of the physical file [record format and data consistency] for the actions against the data.

A change-capable Read Trigger affecting /all access methods/ to the physical data, means that everything that ever reads the data must be *made* /aware/ of the actions of the intermediary. Why? Because the _logic_ built in the access of the physical data _depends_ on receiving the physical row data, and the _logic_ in access of a logical view of the physical data _depends_ on receiving the physical row data. Neither case has logic to deal with whatever some intermediary *wishes\chooses* that those other interfaces will see. The intermediary can not know how to avoid breaking the logic [of for example, a SELECT against the physical data as defined by its record format], only the requester of the data can know what will not break its own coded logic. And if the requester does not know what might happen to the data, it is very likely to suffer from bad assumptions... but of course informing and updating every READer of the possible variations to the data is possible, so they can understand how to deal with it -- argh, I forgot to tell that guy writing reports using SQL SELECT from that new client reporting app!

Giving a change capable Read Trigger is like giving a revolver loaded with five live rounds and one empty. Use of the former equates with a mandate for the latter, of "point-at-self and pull the trigger five times to determine which chamber did not fire", thus seriously wounding or killing self with up to five of six cases, and getting the desired results [that would be no harm] with just the one case. A really bad idea.

I guess it is all moot at this point, as I do not provide code nor support for the DB2 for i5/OS any more, so I would not have to help any customers recover from their failings if such a feature ever transpired. And besides, I am likely done with this platform in a few days. Good luck getting your change-capable read triggers... And then hopefully y'all can avoid the serious tragedies that would surely befall most, if indeed implemented solely as an extension to Read Trigger.

Regards, Chuck