>However depending of the number of records, suddenly a field somewhere in the middle of the table which decrypted correctly earlier will throw up an error and leave the table 1/2 decrypted and useless.
>
>So I have a situation where everything works fine and then I add a single record at the end and a field in the middle which decrypted correctly earlier will not anymore making the table useless . It was because of this that I had to stop using it in my app.
>
>BErnard

Given your use of ALLTRIM() on the encrypted data before decrypting it, I'm not surprised you found this code to be flaky. Instead of encoding the encrypted binary (such as turning it into hex) before stuffing it into the character fields you're stuffing the raw binary into the fields. This means that 0x20 (a.k.a. chr(32)) will occasionally start or end the binary ciphertext being placed into the field. So, instead of the decrypt function being handed the entire 32 bytes of the ciphertext (AES 256 is a 32 byte block cipher) you are handing it 31 (or even 30 if there was a 0x20 on both ends) bytes of the actual ciphertext the FLL produced when encrypting the original plaintext. Granted the FLL could do a much better job of letting you know what is happening or more gracefully handle the exception, but the origin of the problem is with your code not with the FLL.

Another thing that could happen here (it would depend on your data) is that more than 32 bytes of plaintext were being encrypted which would cause the AES block cipher to add another 32 byte block making the ciphertext 64 bytes long which wouldn't fit into the fields as specified in your post. While the stripping of 0x20 was surely happening, this other scenario i provide for completeness. If you had needed the plaintext to be able to fill more than 32 bytes of the 50 byte fields you gave it then you would have needed to use a stream cipher or increase the fields to the appropriate block size multiple for the block cipher you were using.

The number of records in the table have nothing to do with the FLL's encrypt function failing. I'm more than willing to look at this further with you if you think there is still a reproduceable problem somewhere with the latest version of vfpencryption71.fll.