Re: _cipher API vs Qc3Encrypt/Qc3DecryptData vs SQL

M. Lazarus wrote:

With all due respect, I disagree.

1) Does the official SQL state that a read trigger may only be used as an auditing function, thereby there must be a requirement to prevent changes to the buffer?

- Read Triggers are non-SQL. Their intent as designed, was for audit purposes, for which ability to change the data between the trigger and the program defeats that purpose. Also for not being validated by the database, what is received by the program could be anything. If what is coming from the database is desired to be written in any manner desired as provided to a program [as compared to what the program was compiled to receive], just add an abstraction layer between the database and the program; prevent any access to the file except to the abstraction layer.

2) Using your logic, all other applicable triggers (add and update) should also prevent buffer updates. Since that is not the case, I believe that a read trigger should allow the same capability.

- Other triggers are not providing input to the program, but input to the TABLE, with the typing rules enforced by the database.

3) As I pointed out in my original post, a read trigger would be the only way to implement encryption without application program changes.

- If the belief is that a read trigger is the *only* way, then there is a failure in the understanding of what a UDF provides.

CRPence wrote:

A UDF [User Defined Function] is what is used to redefine output [to
a program] reading data from a database file. Use the correct tool for
the requirement.

The Read Trigger is used for auditing what was passed to the program
that issued the read request. If the Read Trigger could change the
data, then what was passed as data to the trigger for audit does not
match what was sent to the program; function defeated. <<SNIP>>

Regards, Chuck