Re: _cipher API vs Qc3Encrypt/Qc3DecryptData vs SQL

Hi Simon,

Thanks for joining in. The diagrams help:

Read trigger:

Database
Trigger program -- trigger receives copy of buffer therefore database maintains control
Database
Application program

Read trigger with change capability:

Database
Trigger program -- trigger receives direct buffer access therefore database cannot control <snip>
Database
Application program

You state that in the latter, "trigger receives direct buffer access therefore database cannot control what is received by application program (could be data entirely unrelated to the row just read)", yet in your diagram, the database takes control of the buffer again before passing it to the application program. Couldn't it make sure the modified buffer satisfies the constraints of the format before passing it to the application program?
Mind you, I tend to agree with you and Chuck that this could easily be used to screw up programs (e.g. Chuck's example of changing the key values, thereby putting them retrieved records out of the sequence expected by the program). But it's also true that UPDATE/BEFORE triggers can wreak havoc by changing key values; a classic example being one that changes the key such that the record will be read again by the application. Which I guess was my initial attitude when reading all this -- if we're allowed to screw things up with an UPDATE/BEFORE trigger, why not with a READ/CHANGE trigger?

In fact, Chuck stated at one point "I am saying that a Read Trigger should not be the place for such a function; perhaps a requested enhancement for a ReWrite trigger.?" What implmentation would make it ok, if the end result is some kind of READ/CHANGE trigger?


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