On Sat, Oct 14, 2017 at 5:56 AM, Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
wrote:
Nathan
How do you know rla to q2cio will avoid the sequential read issue with
encrypted keys?
Do you know or are you theorizing?
When you encrypt a field using a FIELDPROC procedure, and that field that
happens to be an index key, and you afterwards run an SQL select that
references that field in a where clause, for example:
select * from mytable where mykey = '12345'.
The SQE automatically transforms that statement to something like:
select * from mytable where mykey = fieldproc_encode('12345').
Or alternatively changes the statement to something like:
select * from mytable where fieldproc_decode(mykey) = '12345';
There is an article in the IBM i Knowledge Center that covers the
transformation that occurs under the covers in the SQE. The SQE must do
this because a key value like '12345' is stored as an encrypted value in a
record.
So I'm just saying that an ROA handler could invoke the same
fieldproc_encode() or fieldproc_decode() procedure on the key value that
was referenced on RPG SETxx, READxx, and CHAIN statements, before invoking
the corresponding C procedures that are exported from QC2IO.
RPG RLA opcodes can be precisely mapped to QC2IO functions, and RPG record
buffers can be precisely mapped to QC2IO record buffers, whereas the
interface with SQL requires a lot more munging in order to work.
BTW, thanks for offering other potential avenues.
You're welcome to the idea. I have quite a bit of experience using the C
I/O functions. I understand how they work. But I've never used them in an
ROA handler.
midrange.com
