Re: _cipher API vs Qc3Encrypt/Qc3DecryptData vs SQL

A read trigger already enables "a programmatic decision if the person has access to a particular row in a table." The Read Trigger does *not* have the ability to *lie* to the program about what the data was which the read trigger allowed the program to read. Presently to effect that, it is by an abstraction layer; column->UDF, row->UDTF, whatever->other. The access to what rows and columns can be viewed by a user\application can already be implemented with row and columns selection available in the logical views made available of the data; and/or by actual column level authorities.

Argh! A *BEFORE trigger means _before_ the row data has even been _read_ from the file; such a trigger would be pointless because whatever it could write in the buffer would be overwritten by the actual read of the row data. The *AFTER trigger means _after_ the row data has been _read_ from the file; *before* the program has received the data, to enable the Read Trigger program be the arbiter of *whether* the program is allowed to access that row.

What is really being suggested is enabling a change capability to the buffer, which is more like the ALWREPCHG [allow repeated change], but still totally unrelated. If not an entirely new and different type of trigger, a new attribute or borrowing from that /allow/ attribute would be IMO, the only appropriate way to enable changing the read buffer. I expect that when an SQL Read Trigger comes, it may more appropriately enable rewrite according to typed columns, instead of database non-SQL triggers giving away the farm by enabling rewrite of an entire buffer without regard to the /format/ according to the program that reads.

Regards, Chuck