>> If we are able to encrypt/decrypt a particular field, will the SORT on sequential files still work if being used on these encrypted fields ?
The native sort utility will NOT understand the underlying data sort order. It will sort the encrypted bytes, which will have a diffrent order. I don't think you can solve that with 'collating sequences.
You could write your own tool to use calleable sort and provide a comparison routine which which decode and compare.
Conceivably the sort tool would allow you to specify such compare function in a shareable library and use LIB$FIS to activate it, but best I can tell such feature does not exist.
>> 3.What happens with indexed files where the key needs to be encrypted?
Similar. You will only be able to do a 'direct match'. generic key matched ("JOHN" to find "JOHNES") and 'NEXT' operations will be meaningless.
If you go this route I would recommend to consider an artifial primary key in mostly increasing key order, like a record creation timestamp, as the primary storage tool. This will help avoid bucket splitting going crazy to deal with random inserts.
hth,
Hein.
