Thanks Hank,

I fugure it's a lot like golf. Sometimes it's better to be lucky than good and that even a blind squirell finds a nut once in a while.

I suspected there may be some problems with different implementations so, this is the route that I thought was the safest.


>You were wise or lucky: one person's AES implementation may or may not be the same as another person's, based on what the author of the ChilKat controls has written,so it's always wise to use the same tool on each end.
>
>Hank
>
>>I do believe you are on the right track. The StrConv technique would allow me to return a string to VB.net. The ASP/VB app does not need to decode the string but subsequent processing of the table by a VFP app will need to decrypt. I think this will work nicely.
>>
>>I suppose I could have encrypted the string in the VB app but I was not sure the result could be decrypted in the VFP app at a later date.
>>
>>Thanks
>>
>>Glenn
>>
>>>>Thanks for the reply Alex. The VFP COM object provides a function which returns an encrypted string (using Craig's FLL) back to a VB.Net (2.0) program. To accomplish this feat the VFP app must declare a return data type to be compatible with .Net.
>>>
>>>Ahh. I see. I'm not sure of the answer as all my ADO.NET stuff uses SQL Server 2000 exclusively (IOW I do not use COM and DBF).
>>>I assume you use an OleDbConnection object. If you get the digest as text (BASE64), then it should come as a 'text' (memo) field, shouldn't it? How long are the digests? If they are short enhough, it could even be a varchar.