Re: _cipher API vs Qc3Encrypt/Qc3DecryptData vs SQL

Again, for the /Event/ of *READ, its timing is with respect to the activity performed by the database [engine; 'the db', as noted below] *not* with respect to the user or trigger program activity. That is:

_Time_ _Event_ _Description_
*BEFORE *READ Before row is read *by* the db from the file
*AFTER *READ After row is read *by* the db from the file

*Both* of the above Time are *before* the user program ever gets the row data. The second case, *AFTER\*READ, enables passing the row that was retrieved *by* & from the database, to the trigger program. That second case also allows the trigger program to prevent the data being passed to the user-program that wants to READ the row.

As such the *BEFORE\*READ is of no value because the db buffer never has any data until the *AFTER\*READ. Thus nothing could be accomplished in a *BEFORE\*READ trigger that would not be lost by the *AFTER\*READ. Such a trigger can not be added, because it makes no sense.

For case one: The *AFTER\*READ trigger allows the Read Trigger program to obtain and review the row data that the HLL program requested to READ. Thus the Read Trigger has effectively intercepted the read; being a proxy reader. If the Read Trigger wants to 'secure the data' by preventing the HLL READ from being functional, the Read Trigger optionally sends a diagnostic message and then sends an Escape message which causes the db to issue a CPF502B; thus informing by an I/O error, that the HLL READ was not given access to the row. The HLL could be SQL.

For case two: The row that is read remains /the row/; i.e. unchanged from the whatever the Read Trigger might [want to] do to the buffer. The Read Trigger is given, as a proxy reader, a _copy_ of the data [buffer] that will be sent to the HLL program requesting the READ *if* the Read Trigger does not prevent that READ by issuing an Escape message. *If* the ability to change the data as part of a read trigger, then that _copy_ of the data would have to be passed to the program, not the row itself. As it is today, the program that issued the READ always gets /the row/ it requested, irrespective of the existence of any Read Trigger.

So Yes... hopefully it is now clear that the *AFTER\*READ trigger will intercept the user-program READ request, and will prevent both non-SQL and SQL READ activity by having the trigger fail. The failure will be mapped as the I/O error msgCPF502B and each HLL will turn that into its respective I/O error notification... and the db should not make the row data available to the HLL.

Regards, Chuck