I need to connect a Sybase ASE database with a specific charset. I have data with a charset that cannot be read properly by the default charset of Sybase ASE. I know how to connect with "isqln -J" but what I need is a little more complicated.
I have software that connects itself to an ASE database but it doesn't ask for a charset while establishing the connection, so it connects with the default charset.
What I want to ask is, are any of these options possible;
Can I change the default charset of Sybase ASE (not the database charset - I tried changing it, didn't work)
Can I track the connection so just before login (with login trigger etc.) I intercept the connection and change it to my needs (adding "-J" parameter maybe)
I tried changing the database's charset, system's charset, OEM charset, etc. none of these seem to work. The third-party software still connects the database with the default charset, so it cannot read the values with special characters properly
Please be noted -- Sybase ASE can only work fine when server/client's charset are same or compatible -- eg. when using iso_1 on server and client must be iso_1 too, or Server is cp936 and client is cp936 or the subset of cp936-- gb2312... Otherwise on client, you can only get illegal characters like space or square or XXX...
So here's the answer -- please check your ASE server's charset --
sp_helpsort
I don't know what client software you are using, but most general sybase client will call OS's Language settings to set as client's default charset. Then set it on your client's charset -- on linux/unix you can set it with LC_ALL or LANG, on windows, you can set it in Windows Unicode settings.
HTH
Related
I'm running a Windows application on Linux under Wine, that accesses a SQL Server using the ODBC Driver 17 for SQL Server, for Linux.
It runs fine except that I see incorrectly represented the varchars with non-Ascii characters. The nvarchar fields (unicode strings) have no problem.
Example:
select rtrim('Presentación ')
Returns: Presentación
My database has the encoding for varchars defined as iso8859-1, and Wine seems to use the cp1252 page code.
My guess is that the ODBC driver for Linux retrieves correctly the data and transforms them to UTF8, which runs fine (I can see the values correctly if I run my queries directly through isql), but when those strings are passed to my application, under Wine, they must be considered as cp1252 and that's when I see them incorrectly.
Has anyone had the same problem? what could I try?
Thank you.
I am migrating a MS Access back end data file to SQL Server. All data has successfully transferred, and it viewable in SSMS, however, if I open the linked table in the Access front end, all currency field entries that are greater than 0 are blank.
If I run a query that filters currency columns based on their value, I get the correct number of records returned, but still the fields show as blank.
This makes no sense to me, please help.
I would try linking the table using sql driver (this is a long time legacy driver). It been pre-installed on computers since windows XP.
If that does not work, then try linking using the native 11 (or later driver). These drivers are preferred, but they are not installed on each workstation and thus deployment can be a hassle.
And to prevent the need to configure each workstation? Always (but always) use a FILE dsn. This is suggested because Access will convert the connection automatic to DSN-less. This means that you not have to setup a DSN on each workstation (but you STILL require the native driver 11-17 having been installed on each workstation, and that driver will have to match what you linked with.
If EITHER of the above STILL does not display the money type columns?
Then this is a regional setting. (the regional setting of the sql server is not matching what your regional settings are on the client workstation.
So, then create a new DSN (as noted always FILE).
And during the re-link process try selecting the regional settings:
So, you should not have to change the "money" type to decimal. And doing so could introduce all kinds of issues.
So, try the above first. Both the legacy (windows built in) "sql driver", and the natve 11-17 drivers work for me WITHOUT having to select the above regional settings, but if both sql legacy and the newer native 11 (or later) drivers don't work, then try re-linking again and selecting the above option.
NOTE ALSO that you do NOT get the above panel during a re-link, nor do you get the above panel during a re-fresh. Nor do you get the above panel if you select a existing DSN. You MUST create a new DSN to get/see/use the above panel. It ONLY appears one time, and ONLY during the time you create a new DSN - not during re-use or a re-link or a re-select of a existing DSN.
Wow, this takes me back.
Assuming you're using an ODBC DSN to set the connection for the linked tables, set the ODBC data source to use the "SQL Server Native Client" driver, not the "SQL Server" driver. As I recall you can't change the driver for a DSN, so you'll have to remove your existing one and create a new one.
To get there:
Open start menu > type "odbc data sources" > click to open odbc data sources > click add > scroll all the way to the bottom of the drivers list and choose SQL Server Native Client as the driver > set up the rest of the DSN according to your environment.
I've got a funny issue trying to insert non-ASCII characters into a SQL Server database, using the Microsoft ODBC driver for Linux. The problem is it seems to be assuming different character sets when sending and receiving data. For info, the server collation is set to Latin1_General_CI_AS (I'm only trying to insert European accent characters).
Testing with tsql (which came with FreeTDS), everything is fine. On startup, it outputs the following:
locale is "en_GB.utf8"
locale charset is "UTF-8"
using default charset "UTF-8"
I can both insert and select a non-ASCII value into a table.
However, using my own utility which uses the ODBC API, it's not working. When I do a select query, the data comes back in UTF-8 character set as desired. However if I insert UTF-8 characters, they get corrupted.
SQL > update test set a = 'Béthune';
Running SQL: update test set a = 'Béthune'
Query executed OK: 1 affected rows
SQL > select * from test;
Running SQL: select * from test
+------------+
| a |
+------------+
| Béthune |
+------------+
If I instead insert the data encoded in ISO-8859-1, then that works correctly, however the select query will still return it encoded in UTF-8!
I've already got the locale set to en_GB.utf8, and a client charset of UTF-8 in the database connection details. Aargh!
FWIW I seem to be getting the same problem whether I use the FreeTDS driver or the official Microsoft driver.
EDIT: Just realised one relevant point, which is that in this test program, it isn't using a prepared statement with bound variables. In other words, the update SQL is passed directly into the SQLPrepare call. Something in ODBC is definitely doing an iconv translation, but evidently not to the correct character set!
#0 0x0000003d4c41f850 in iconv () from /lib64/libc.so.6
#1 0x0000003d4d83fd94 in ?? () from /usr/lib64/libodbc.so.2
#2 0x0000003d4d820465 in SQLPrepare () from /usr/lib64/libodbc.so.2
I'll try compiling my own UnixODBC to see better what's going on.
EDIT 2: I've built UnixODBC from source to debug what it's doing, and the problem is nl_langinfo(CODESET) reports back ISO-8859-1. That is strange, since the man page for it says it's the same string you get from locale charmap, which returns UTF-8. I'm guessing that's the problem but still not sure how to solve.
A colleague at work has just figured out the solution for FreeTDS at least.
For a direct driver connection (SQLDriverConnect()), adding ClientCharset=UTF-8;ServerCharset=CP1252; to the connection string fixed the problem
For a connection via the driver manager (SQLConnect()), I can add these lines to the connection settings in odbc.ini:
client charset = UTF-8
server charset = CP1252
Can't yet figure out a solution using the Microsoft driver ...
A solution for Microsoft ODBC Driver might be to set a proper value into the LANG environment variable.
Make sure you have your required locale installed and configured. Also make sure that the LANG environment variable is set correctly for the user you are running your application under. This might be tricky for daemons. For example to make it work for PHP with Apache2 I had to add export LANG=en_US.utf8 into /etc/apache2/envvars.
Good day,
i have a Sybase ASE 12.5 database on windows NT server
the database default charachterset is CP850
i'm trying to connect to it using "TOAD for sybase" ,which is on my windows 7 machine
whatever character set i choose for TOAD (utf8,cp1256..), the data are shown in latin letters instead of arabic
i tried disabling the "server character set conversion" ,and disabling the client side conversion,but still no hope
any ideas how to solve this?
CP850 is the character set for Western Europe, so that would explain the latin. If the character set used by the client does not match what is used in the server, then it defaults to English.
You need to change the character set of the server to match what you wish to use for the client, or install the UTF character set in the Server to allow Unicode use.
The Sybase ASE documentation explains the details of charactersets.
the problem were in the server itself, it was corrupted during cloning.
thanks for all the answers
Once again with the charset issues when talking to DB's :)
I have two enviroments running Zend Server. Bot of these communicate to a SQL Server 2000 using the mssql extension. None of them has any value given for the charset in the settings of the extension. For one it works and for the other one it returns data in the wrong encoding.
The problem became noticed when this data was beeing inserted into a MySQL database and it screamed with SQLSTATE[HY000]: General error: 1366 Incorrect string value: '\xF6m' for column 'cust_lastname' at row 1.
I tried using SET NAMES utf8 to get the SQL Server connection to return the correct data, but it complains and says that NAMES is not a recognized SET statement. Looking around most people even recommend using this but it doesn't seem to be part of SQL Server 2000 :)
So, what should I do? How do I, WITHOUT fiddling with the SQL Server database/tables, tell it to send me the data in UTF-8 encoded format?
EDIT:
Some more info...
SQL Server uses the Finnish_Swedish_CI_AS collation
MySQL has every table in UTF-8 format and uses utf8_unicode_ci
I didn't find a good solution and ended up converting to and from utf8 in my application. If this is encapsulated within a class it doesn't riddle the code. But a way to actually tell the SQL server which encoding to use during communication would be better.