>>You could also use the record's surrogate primary key as the encryption key. (Or STR() or TRANSFORM() of it if it's an integer and you need a string.)
>>
>>Cheers,
>>Rich.
>
>Yes, it occurred to me to use the primary integer key of the record which contains the memo field. (The seed is an integer.) That won't change because I don't mess with my primary keys. I thought I would xor that field with something else in the record that won't change (like the creation datetime of the record) so the seed won't be too easy to guess.

If you think the seed will be easy to guess, I'm glad your users aren't mine! ;)

>But this still leaves the problem of protecting the source code and/or guarding against decompilation. Are you concerned about that?

In my current specific case, not at all. It's probably overkill that I've encrypted the passwords.

I still think in most cases (but I don't know yours!) that it's a pretty long shot that someone who wants to get at your encrypted data will (a) decompile the source code to find the encrypt/decrypt algorithm and (b) look through all the prgs/scxs which may call the functions, to determine what's being passed to them as a key.

Anyway, if you ARE concerned about your source code being decompiled, there are very good products out there for encrypting your source code. The one I know by name is ReFox. The company who makes ReFox advertises on the U.T., they've been mentioned in several threads in the past few days, but I forget the company name. You can search the threads for "refox".

HTH,
Rich.