>>I sense frustration in your voice/writing. I am not arguing with you; I am just trying to find a condition when storing the string with un-printable characters in a Char type field fails. It could be a certain setting of the SQL Server; which I am willing to duplicate. Once I know that there is a potential problem (that I can duplicate), I can plan an alternative approach. And I am going to test the varbinary with the ODBC but not sure if it will work.
>
>Yes, exactly, frustration.
>I am trying to tell you what you should use based on experience and you are simply resisting with no solid base. I have already seen problems in encrypted fields stored in SQL Server as char, varchar fields (nchar, nvarchar are totally out of the equation). I am trying to tell you that in N different ways to no avail, so I surrender.
>
>One final thing, a clear test for you. In VFP suppose your encrypted string value is:
>
>

>local lcEncrypted
>lcEncrypted = "very very"+chr(0)+" secret password"
>create cursor vfpCursor (myPwd c(200))
>insert into vfpCursor (myPwd) values (m.lcEncrypted)
>
>? m.lcEncrypted == left(vfpCursor.myPwd, len(m.lcEncrypted)) && VFP should store it in a char field without loss
>

>
>Now store this value in SQL Server using char, varchar, nvarchar as you wish and then retrieve to see what you have got back.

The cipher() function I use does not allow chr(0). So, the above example is not applicable in this case.