Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Japanese Windows

5 posts in General Discussion Last posting was on 2005-03-07 16:41:43.0Z
Georg Jung Posted on 2005-03-02 13:52:39.0Z
From: "Georg Jung" <georg.jung@atosorigin.com>
Newsgroups: ianywhere.public.general
Subject: Japanese Windows
Lines: 39
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
NNTP-Posting-Host: whitechalk.cgtec.sema.de
X-Original-NNTP-Posting-Host: whitechalk.cgtec.sema.de
Message-ID: <4225c527@forums-1-dub>
Date: 2 Mar 2005 05:52:39 -0800
X-Trace: forums-1-dub 1109771559 192.76.140.113 (2 Mar 2005 05:52:39 -0800)
X-Original-Trace: 2 Mar 2005 05:52:39 -0800, whitechalk.cgtec.sema.de
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:4179
Article PK: 8054

Hello

We have a problem during insert values on Japanese Windows.
Database has Collation 1252LATIN1.

The insert command for the database is made dynamically in Powerscript
without parameters - the problem is that á see below - On Japanese windows
this is a lead byte. Is there any hope to solve this? using the collation
1252LATIN1

Starting the Server with -ct- does not help.
ASA Version 9.0.1.1751

Hope for help...

Georg Jung

Insert into test( COL1,COL2) values ( 'Pittá', 'D-AD-I')
is the string.
The ODBC Log is:

scoutpde 5ec-6c8 EXIT SQLExecDirect with return code -1 (SQL_ERROR)
HSTMT 01C718D8
UCHAR * 0x05630D10 [ -3] "Insert into <.......>\ 0"
SDWORD -3

DIAG [42000] [Sybase][ODBC Driver]Syntax error or access violation (0)

scoutpde 5ec-6c8 ENTER SQLErrorW
HENV 01C714F0
HDBC 01C71598
HSTMT 01C718D8
WCHAR * 0x0012DEF0 (NYI)
SDWORD * 0x0012DF3C
WCHAR * 0x0012DAF0
SWORD 512
SWORD * 0x0012DF44


John Smirnios Posted on 2005-03-02 16:08:59.0Z
From: John Smirnios <smirnios_at_sybase_dot_com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: ianywhere.public.general
Subject: Re: Japanese Windows
References: <4225c527@forums-1-dub>
In-Reply-To: <4225c527@forums-1-dub>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Original-NNTP-Posting-Host: iarouter.sybase.com
Message-ID: <4225e517$1@forums-2-dub>
X-Original-Trace: 2 Mar 2005 08:08:55 -0800, iarouter.sybase.com
Lines: 63
X-Original-NNTP-Posting-Host: forums-2-dub.sybase.com
X-Original-Trace: 2 Mar 2005 08:08:56 -0800, forums-2-dub.sybase.com
NNTP-Posting-Host: forums-master.sybase.com
X-Original-NNTP-Posting-Host: forums-master.sybase.com
Date: 2 Mar 2005 08:08:59 -0800
X-Trace: forums-1-dub 1109779739 10.22.108.75 (2 Mar 2005 08:08:59 -0800)
X-Original-Trace: 2 Mar 2005 08:08:59 -0800, forums-master.sybase.com
X-Authenticated-User: ngsysop
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:4182
Article PK: 8060

The real question is, "how did your application get a hold of CP1252
data while running on a Japanese machine in the first place?" It
shouldn't have come from the database because it would have been
translated to cp932 for you.

Assuming you really do legitimately have cp1252 data in your app, you
should be able to force your connection to be cp1252 by adding a
"charset=cp1252" to your connection string. However, your app will not
be able to display cp1252 data without manually converting it to the OS
(Japanese) charset. That's the only charset Japanese Windows understands
(unless you are using the UTF16 ["Wide"] OS entrypoints).

-john.

--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering

Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer

Georg Jung wrote:
> Hello
>
> We have a problem during insert values on Japanese Windows.
> Database has Collation 1252LATIN1.
>
> The insert command for the database is made dynamically in Powerscript
> without parameters - the problem is that á see below - On Japanese windows
> this is a lead byte. Is there any hope to solve this? using the collation
> 1252LATIN1
>
> Starting the Server with -ct- does not help.
> ASA Version 9.0.1.1751
>
> Hope for help...
>
> Georg Jung
>
> Insert into test( COL1,COL2) values ( 'Pittá', 'D-AD-I')
> is the string.
> The ODBC Log is:
>
> scoutpde 5ec-6c8 EXIT SQLExecDirect with return code -1 (SQL_ERROR)
> HSTMT 01C718D8
> UCHAR * 0x05630D10 [ -3] "Insert into <.......>\ 0"
> SDWORD -3
>
> DIAG [42000] [Sybase][ODBC Driver]Syntax error or access violation (0)
>
> scoutpde 5ec-6c8 ENTER SQLErrorW
> HENV 01C714F0
> HDBC 01C71598
> HSTMT 01C718D8
> WCHAR * 0x0012DEF0 (NYI)
> SDWORD * 0x0012DF3C
> WCHAR * 0x0012DAF0
> SWORD 512
> SWORD * 0x0012DF44
>
>


Georg Jung Posted on 2005-03-03 07:50:02.0Z
From: "Georg Jung" <georg.jung@atosorigin.com>
Newsgroups: ianywhere.public.general
References: <4225c527@forums-1-dub> <4225e517$1@forums-2-dub>
Subject: Re: Japanese Windows
Lines: 76
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
NNTP-Posting-Host: whitechalk.cgtec.sema.de
X-Original-NNTP-Posting-Host: whitechalk.cgtec.sema.de
Message-ID: <4226c1aa$1@forums-1-dub>
Date: 2 Mar 2005 23:50:02 -0800
X-Trace: forums-1-dub 1109836202 192.76.140.113 (2 Mar 2005 23:50:02 -0800)
X-Original-Trace: 2 Mar 2005 23:50:02 -0800, whitechalk.cgtec.sema.de
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:4192
Article PK: 8069

hi,

thanks for the answer, we will try it... - and perform a good test.

- Georg

"John Smirnios" <smirnios_at_sybase_dot_com> schrieb im Newsbeitrag
news:4225e517$1@forums-2-dub...

> The real question is, "how did your application get a hold of CP1252
> data while running on a Japanese machine in the first place?" It
> shouldn't have come from the database because it would have been
> translated to cp932 for you.
>
> Assuming you really do legitimately have cp1252 data in your app, you
> should be able to force your connection to be cp1252 by adding a
> "charset=cp1252" to your connection string. However, your app will not
> be able to display cp1252 data without manually converting it to the OS
> (Japanese) charset. That's the only charset Japanese Windows understands
> (unless you are using the UTF16 ["Wide"] OS entrypoints).
>
> -john.
>
> --
> John Smirnios
> Senior Software Developer
> iAnywhere Solutions Engineering
>
> Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
> Developer Community at http://www.ianywhere.com/developer
>
> Georg Jung wrote:
> > Hello
> >
> > We have a problem during insert values on Japanese Windows.
> > Database has Collation 1252LATIN1.
> >
> > The insert command for the database is made dynamically in Powerscript
> > without parameters - the problem is that á see below - On Japanese
windows
> > this is a lead byte. Is there any hope to solve this? using the
collation
> > 1252LATIN1
> >
> > Starting the Server with -ct- does not help.
> > ASA Version 9.0.1.1751
> >
> > Hope for help...
> >
> > Georg Jung
> >
> > Insert into test( COL1,COL2) values ( 'Pittá', 'D-AD-I')
> > is the string.
> > The ODBC Log is:
> >
> > scoutpde 5ec-6c8 EXIT SQLExecDirect with return code -1
(SQL_ERROR)
> > HSTMT 01C718D8
> > UCHAR * 0x05630D10 [ -3] "Insert into <.......>\ 0"
> > SDWORD -3
> >
> > DIAG [42000] [Sybase][ODBC Driver]Syntax error or access violation (0)
> >
> > scoutpde 5ec-6c8 ENTER SQLErrorW
> > HENV 01C714F0
> > HDBC 01C71598
> > HSTMT 01C718D8
> > WCHAR * 0x0012DEF0 (NYI)
> > SDWORD * 0x0012DF3C
> > WCHAR * 0x0012DAF0
> > SWORD 512
> > SWORD * 0x0012DF44
> >
> >
>


Georg Jung Posted on 2005-03-07 09:40:25.0Z
From: "Georg Jung" <georg.jung@atosorigin.com>
Newsgroups: ianywhere.public.general
References: <4225c527@forums-1-dub> <4225e517$1@forums-2-dub> <4226c1aa$1@forums-1-dub>
Subject: Re: Japanese Windows - Update
Lines: 110
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
NNTP-Posting-Host: whitechalk.cgtec.sema.de
X-Original-NNTP-Posting-Host: whitechalk.cgtec.sema.de
Message-ID: <422c2189$1@forums-1-dub>
Date: 7 Mar 2005 01:40:25 -0800
X-Trace: forums-1-dub 1110188425 192.76.140.113 (7 Mar 2005 01:40:25 -0800)
X-Original-Trace: 7 Mar 2005 01:40:25 -0800, whitechalk.cgtec.sema.de
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:4202
Article PK: 8075

Hi,

we tested your suggestion - no success.
In my opinion - it is not possible to input the data into the database in
this manner, because:
The SQL String is executed in Powerbuilder 9:
...
ls_string = "Insert into test( COL1,COL2) values ( 'Pittá', 'D-AD-I')"
Execute immediate :ls_string using sqlca;
...

The SQL string is invalid on Japanese Windows (á is a lead byte) -
therefore no success anyway in this manner.
Does character translation takes place while performing this SQL - assumed
Character translation is turned on during startup of the DB Server

Maybe a success can be performed changing the SQL:
...
ls_1 = 'Pittá'
ls_2 = 'D-AD-I'
Insert into test( COL1,COL2) values (:ls_1,:ls_2);
...
- what do yout think ?

Regards
Georg



"Georg Jung" <georg.jung@atosorigin.com> schrieb im Newsbeitrag
news:4226c1aa$1@forums-1-dub...

> hi,
>
> thanks for the answer, we will try it... - and perform a good test.
>
> - Georg
>
> "John Smirnios" <smirnios_at_sybase_dot_com> schrieb im Newsbeitrag
> news:4225e517$1@forums-2-dub...
> > The real question is, "how did your application get a hold of CP1252
> > data while running on a Japanese machine in the first place?" It
> > shouldn't have come from the database because it would have been
> > translated to cp932 for you.
> >
> > Assuming you really do legitimately have cp1252 data in your app, you
> > should be able to force your connection to be cp1252 by adding a
> > "charset=cp1252" to your connection string. However, your app will not
> > be able to display cp1252 data without manually converting it to the OS
> > (Japanese) charset. That's the only charset Japanese Windows understands
> > (unless you are using the UTF16 ["Wide"] OS entrypoints).
> >
> > -john.
> >
> > --
> > John Smirnios
> > Senior Software Developer
> > iAnywhere Solutions Engineering
> >
> > Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
> > Developer Community at http://www.ianywhere.com/developer
> >
> > Georg Jung wrote:
> > > Hello
> > >
> > > We have a problem during insert values on Japanese Windows.
> > > Database has Collation 1252LATIN1.
> > >
> > > The insert command for the database is made dynamically in Powerscript
> > > without parameters - the problem is that á see below - On Japanese
> windows
> > > this is a lead byte. Is there any hope to solve this? using the
> collation
> > > 1252LATIN1
> > >
> > > Starting the Server with -ct- does not help.
> > > ASA Version 9.0.1.1751
> > >
> > > Hope for help...
> > >
> > > Georg Jung
> > >
> > > Insert into test( COL1,COL2) values ( 'Pittá', 'D-AD-I')
> > > is the string.
> > > The ODBC Log is:
> > >
> > > scoutpde 5ec-6c8 EXIT SQLExecDirect with return code -1
> (SQL_ERROR)
> > > HSTMT 01C718D8
> > > UCHAR * 0x05630D10 [ -3] "Insert into <.......>\ 0"
> > > SDWORD -3
> > >
> > > DIAG [42000] [Sybase][ODBC Driver]Syntax error or access violation
(0)
> > >
> > > scoutpde 5ec-6c8 ENTER SQLErrorW
> > > HENV 01C714F0
> > > HDBC 01C71598
> > > HSTMT 01C718D8
> > > WCHAR * 0x0012DEF0 (NYI)
> > > SDWORD * 0x0012DF3C
> > > WCHAR * 0x0012DAF0
> > > SWORD 512
> > > SWORD * 0x0012DF44
> > >
> > >
> >
>
>


John Smirnios Posted on 2005-03-07 16:41:43.0Z
From: John Smirnios <smirnios_at_sybase_dot_com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: ianywhere.public.general
Subject: Re: Japanese Windows - Update
References: <4225c527@forums-1-dub> <4225e517$1@forums-2-dub> <4226c1aa$1@forums-1-dub> <422c2189$1@forums-1-dub>
In-Reply-To: <422c2189$1@forums-1-dub>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
NNTP-Posting-Host: iarouter.sybase.com
X-Original-NNTP-Posting-Host: iarouter.sybase.com
Message-ID: <422c8447$1@forums-1-dub>
Date: 7 Mar 2005 08:41:43 -0800
X-Trace: forums-1-dub 1110213703 10.25.106.45 (7 Mar 2005 08:41:43 -0800)
X-Original-Trace: 7 Mar 2005 08:41:43 -0800, iarouter.sybase.com
Lines: 155
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:4203
Article PK: 8077

Okay, I've spoken with our ODBC gurus and your problems are bigger than
I suspected because of the way ODBC behaves. Whenever the ODBC driver
manager (which is provided by Microsoft, not ASA) is talking to an ODBC
driver that supports Unicode entrypoints (which includes the ASA
driver), only the Unicode entrypoints are used. All strings coming from
an application are converted to Unicode before they are passed to the
driver. As far as we know, the driver manager *always* assumes that
non-Unicode strings are in the OS native character set so you cp1252
strings in a SJIS->UTF16 conversion before it ever gets to the ASA driver.

Bound host variables are not converted to UNICODE though. However, the
ODBC driver must scan the variables to look for canonical escape
sequences (for dates, etc). That scanning is done by the ASA ODBC driver
and it assumes that non-Unicode data is in the OS charset (not in the
"charset=" charset of your connection string). You can turn off ODBC
escapes by changing your ODBC connection attributes.

If you turn off escapes and all non-ASCII letters are in host variables
you may just happen to be lucky enough to get this to work, HOWEVER, the
correct approach is either use all UTF-16 or all OS charset because ODBC
on Windows assumes *all* data is in one of those two encodings.

-john.

--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering

Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer

Georg Jung wrote:

> Hi,
>
> we tested your suggestion - no success.
> In my opinion - it is not possible to input the data into the database in
> this manner, because:
> The SQL String is executed in Powerbuilder 9:
> ...
> ls_string = "Insert into test( COL1,COL2) values ( 'Pittá', 'D-AD-I')"
> Execute immediate :ls_string using sqlca;
> ...
>
> The SQL string is invalid on Japanese Windows (á is a lead byte) -
> therefore no success anyway in this manner.
> Does character translation takes place while performing this SQL - assumed
> Character translation is turned on during startup of the DB Server
>
> Maybe a success can be performed changing the SQL:
> ...
> ls_1 = 'Pittá'
> ls_2 = 'D-AD-I'
> Insert into test( COL1,COL2) values (:ls_1,:ls_2);
> ...
> - what do yout think ?
>
> Regards
> Georg
>
>
>
> "Georg Jung" <georg.jung@atosorigin.com> schrieb im Newsbeitrag
> news:4226c1aa$1@forums-1-dub...
>
>>hi,
>>
>>thanks for the answer, we will try it... - and perform a good test.
>>
>>- Georg
>>
>>"John Smirnios" <smirnios_at_sybase_dot_com> schrieb im Newsbeitrag
>>news:4225e517$1@forums-2-dub...
>>
>>>The real question is, "how did your application get a hold of CP1252
>>>data while running on a Japanese machine in the first place?" It
>>>shouldn't have come from the database because it would have been
>>>translated to cp932 for you.
>>>
>>>Assuming you really do legitimately have cp1252 data in your app, you
>>>should be able to force your connection to be cp1252 by adding a
>>>"charset=cp1252" to your connection string. However, your app will not
>>>be able to display cp1252 data without manually converting it to the OS
>>>(Japanese) charset. That's the only charset Japanese Windows understands
>>> (unless you are using the UTF16 ["Wide"] OS entrypoints).
>>>
>>>-john.
>>>
>>>--
>>>John Smirnios
>>>Senior Software Developer
>>>iAnywhere Solutions Engineering
>>>
>>>Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
>>>Developer Community at http://www.ianywhere.com/developer
>>>
>>>Georg Jung wrote:
>>>
>>>>Hello
>>>>
>>>>We have a problem during insert values on Japanese Windows.
>>>>Database has Collation 1252LATIN1.
>>>>
>>>>The insert command for the database is made dynamically in Powerscript
>>>>without parameters - the problem is that á see below - On Japanese
>>
>>windows
>>
>>>>this is a lead byte. Is there any hope to solve this? using the
>>
>>collation
>>
>>>>1252LATIN1
>>>>
>>>>Starting the Server with -ct- does not help.
>>>>ASA Version 9.0.1.1751
>>>>
>>>>Hope for help...
>>>>
>>>> Georg Jung
>>>>
>>>>Insert into test( COL1,COL2) values ( 'Pittá', 'D-AD-I')
>>>>is the string.
>>>>The ODBC Log is:
>>>>
>>>>scoutpde 5ec-6c8 EXIT SQLExecDirect with return code -1
>>
>>(SQL_ERROR)
>>
>>>> HSTMT 01C718D8
>>>> UCHAR * 0x05630D10 [ -3] "Insert into <.......>\ 0"
>>>> SDWORD -3
>>>>
>>>> DIAG [42000] [Sybase][ODBC Driver]Syntax error or access violation
>
> (0)
>
>>>>scoutpde 5ec-6c8 ENTER SQLErrorW
>>>> HENV 01C714F0
>>>> HDBC 01C71598
>>>> HSTMT 01C718D8
>>>> WCHAR * 0x0012DEF0 (NYI)
>>>> SDWORD * 0x0012DF3C
>>>> WCHAR * 0x0012DAF0
>>>> SWORD 512
>>>> SWORD * 0x0012DF44
>>>>
>>>>
>>>
>>
>
>