If one uses the encrypt and decrypt triggers (specifically the decrypt trigger) to encode and decode a field in the database, but leave it in \'plain\' in the uniface code, the decrypt trigger code would be something like. <$fieldname>=$decode(\"BLOWFISH\",<$fieldname>,\"My super secret key\") Unfortunately, this code counts as modifying this field, and therefore fires the lock trigger on the entity. Thus meaning that all entities with encrypted data are defacto paranoid locking, regardless of the setting on the component. The wish is for a \'special\' function like $format, which can be used in this trigger to indicate that the field is decoded into itself, without firing the lock trigger, or indeed setting $occmod. The justification for this behaviour is that the encrypt trigger and decrypt trigger must, of necessity, be equal and opposite, and therefore the decrypt trigger has no effect on what will be saved to the database, and has therefore not changed the database values even though it has decrypted the field in the uniface code. The current work-around is to add a non database field and decrypt the stored field into that, however, this then increases bandwidth and memory requirements as both pieces of data have to be stored/passed separately.

Use Case

Allowing for any form of non-paranoid locking when reading encrypted data.




Proc Code

Operating System

Not Applicable



Leave a Reply