CTD151 vs CTD51 char 128-200 Ascii vs Unicode reading SQL Data

forum.gupta.bugreport (2005-2010)
NewsgroupServer
Robot
Robot
Posts: 118939
Joined: 24 Feb 2017, 12:00
Location: World wide

CTD151 vs CTD51 char 128-200 Ascii vs Unicode reading SQL Data

Post by NewsgroupServer » 07 Feb 2008, 13:26

 Posted by:  Philip Hautekiet 

We're storing encrypted data (paswords, etc,...) in database table columns.

Retrieving this data (> ascii 128) doesn't give the same result in CTD51.

As attachment

a/ the appliction in CTD15 and CTD51
b/ the .sql script to generate a test table on sqlbase
c/ A screenshot with the different results.

How should we solve this?
We're using Sqlbase, Oracle and Sql Server

Thanks in advance.

Attachment: pwdiff.sql
Attachment: pw51.apt
Attachment: pw51.apt
Attachment: pwdif.jpg

NewsgroupServer
Robot
Robot
Posts: 118939
Joined: 24 Feb 2017, 12:00
Location: World wide

CTD151 vs CTD51 char 128-200 Ascii vs Unicode reading SQL Data

Post by NewsgroupServer » 07 Feb 2008, 13:32

 Posted by:  Philip Hautekiet 

We found this:

http://www.alanwood.net/demos/charsetdiffs.html

Is there a way to read old data like it was stored originally?

NewsgroupServer
Robot
Robot
Posts: 118939
Joined: 24 Feb 2017, 12:00
Location: World wide

CTD151 vs CTD51 char 128-200 Ascii vs Unicode reading SQL Data

Post by NewsgroupServer » 07 Feb 2008, 18:36

 Posted by:  Jeff Luther 

Try this variation of your PalToAscii function:
Function: PalToANSI
Description:
Returns
String:
Parameters
String: pString
Static Variables
Local variables
String: sRes
Actions
While pString != ''
! convert pString to ANSI *before* lopping it and getting its char #
Call SalStrToMultiByte( pString, pString, ENC_ANSI )
Set sRes = sRes || ' ' || SalNumberToStrX(SalStrLop(pString),0)
Return sRes

You can see in the attached jpg that converting to multibyte (ansi)
first, then manipulating the value, gives you the ansi char #. I think
this is what you are looking for. Note that I just added a colANSI
column to your TW.

NOTE #2, though, the you still need to keep in mind what you are
comparing: If you retrieve a pw from the db into a string var., it will
be in unicode (because the var. is unicode). And if you compare that to
some value a user types into a login data field, that too will be
unicode. You may have to convert *both* strings to ANSI and then
compare. (Though maybe both in unicode will compare ok too.)

Your issue appears to be that you are comparing a db pw *in a unicode
var* with some other source that is already in ANSI. If that's the case,
then PalToANSI() should help.

"We're storing encrypted data (paswords, etc,...) in database table
columns." - thus, they are in ANSI, right? And when you fetch back into
your appl. and compare, aren't you comparing to a user's field input,
which is also in unicode?

The 'secret' to remember is that v5.1 is *always* going to define string
vars, fields, columns, etc. in UNICODE/double-byte format. That is now
how all the SAL and VIS string functions work now in v5.1, how any
string type objects (fields, columns) work, and so on.

Best Regards,
Jeff @ PC Design
info. & samples: www.JeffLuther.net/unify/


Attachment: pw_char_ToANSI.jpg

Return to “gupta.bugreport”

Who is online

Users browsing this forum: Ccbot [Crawler] and 0 guests