>>would give gibberish with cryptor in tho loop, as the copied table is raw data again.
>>
>>>Yep, I have had the SET TABLEVALIDATE save me a few times before too. What I've done in the past is once I was able to open the table, I copied it to another table then reindexed the new table...delete the 1st table and then rename the 2nd one to the 1st one.
>>>
>
>Actually no. This was the process.
>
>1) Tell Cryptor that table aa.dbf and aa.fpt are encrypted.
>2) Open Table aa.dbf and aa.fpt with modi comm. Results are unencrypted.
>3) Save tables from modi comm as aa1.dbf and aa1.fpt. Results are unencrypted.
>4) Copy aa.cdx to aa1.cdx with windows explorer since cdx is not encrypted.
>5) SET TABLEVALIDATE TO 8
>6) Use aa1. This was the crucial step that SET TABLEVALIDATE allowed.
>7) COPY TO aa WITH CDX. Results are encrypted again and ready to use.

If you compare your steps to the ones proposed you'll see some difference. I'm pretty sure that

1) I was able to open the table, I copied it to another table then reindexed the new table
will give you unencrypted table (as "copied it to another table">> copy to command)

2) delete the 1st table
unambigous

3) then rename the 2nd one to the 1st one.
has the application having hooks for that filestem/ext couples awaiting encrypted data to the filestem.crb-key while the file renamed is clear.

I guess in your case it would have been enough to try to open the aa.dbf/fpt/cdx with tablevalidate set to ignore problems.

regards

thomas