Back after running your test case...
Note I've attached a mod. to your test. Take a look at this one, since my changes are essentially to make the test 'self-contained' without having to run external DML or DDL files. This helps dev. and QA automate their testing. You'll see I added to form create the DDL and enough DML rows to get some data in the DB table, plus on destroy drop the table. If you use this model for test cases for us, it really helps. Thanks.
I also saw this file was missing: C:\!Dev\Phoenix Dev\Centura60\txt6.0\dasybsal.apl
and I included TD's sybsal32.apl
-- If your DA version has the TD APL as a File Include, no problem. But if that DA apl has included sybsal32.apl in it, I'd caution you that this could be a problem because future TD releases might make changes to sybsal32.apl and if you are using a hard-coded version in DA then you'd miss any changes. (I've seen this a number of times with users, especially for the TD APLs, where declarations changed from old 4.2 with ANSI 'A' funct. decls. to newer Unicode 'W' decls. and then wondered why their VT calls were failing.)
So, to your test case. I do not get any error when I run that with our Sybase v15, either with char_convert ON of OFF. In SAM_Create you'll see I turn this ON before the DDL and DML statements, then keep it ON when I click the Go button. No error.
Couple thoughts and questions:
** What version of the Sybase DB server is your customer on?
** Is their Sybase DB Unicode-enabled?
** I talked with our TD/router developer who believes as I do: It seems that they do not have a Unicode DB which is why this conversion is failing. Our Sybase v15 test DB at the office is. Since you still use the 'Centura' word even for TD v6 it seems your app. is being ported from earlier TD prior to 5.1, when TD used ANSI/single-byte strings.
** The dev. also mentioned that this char_convert issue might be entered in as an enhancement request, but this is not a bug. Sounds harsh perhaps, but TD since 5.x and later is now in Unicode, fundamentally there are 2 basic options:
1 - configure/set up the DB so it can handle Unicode strings. Or add code to Set char_convert off, for example. You have a way, based on that previous forum thread, except your users don't want to change their DB for char_convert.
2 -- (more difficult) might be that you would have to convert your Unicode strings to ANSI (using SalStrToMultiByte) before the INSERT/UPDATE calls, and then on fetch back the ANSI string must be converted back to Unicode (using SalStrToWideChar) if you want to use and display the string in TD. Like in the table window of your test case.
Last, Sybase NVARCHAR (your test case uses VARCHAR) -- I recommended this in that other forum thread, info. for this type here:
http://dcx.sybase.com/1200/en/dbreferen ... rying.html
NVARCHAR is the correct DB column type for Unicode data, as the link says: "The NVARCHAR data type stores Unicode character data, up to 32767 characters."
I suggest you change the test to do a DLL call with nvarchar(30) and see if that works for you.
You do not have the required permissions to view the files attached to this post.