另外，还有一种选择是，服务器端和客户端都使用iso_1字符集，虽然iso_1字符集并不直接支持中文字符，但我们将服务器端和客户端都设置成iso_1字符集后，系统也不会在客户端和服务器端进行字符转换，它只不过将一个汉字的两个字节当做两个单独字符来处理，一般情况下没有问题。但当执行like匹配查询的时候，它有可能返回不正确的结果，原因是服务器端是根据单字节去匹配查询条件的，很可能会有前一个汉字的第二字节与后一个汉字的第一字节的内码组合符合查询条件，被服务器端作为查询结果返回来。
2.5 如何查看服务器端、客户端字符集
查看服务器端字符集：
在isql环境中执行：
1>; sp_helpsort
2>; go
查看客户端字符集：
在isql环境中执行：
1>; select @@client_csname
2>; go
3. 错误处理篇
3.1 为什么会出现字符集转换失败
1. 当字符存在于客户端字符集中但在服务器字符集中不存在时，Adaptive Server的字符集转换将报告转换错误，反之亦然。
用户会碰到下面的错误消息：
Msg 2402,Severity 16 (EX_USER):
Error converting client characters into server's character set. Some character(s) could not be converted.
转换错误会阻止插入与更新语句的执行。如果发生此情况，请检查数据中有问题的字符并替换它们。
2. 当客户端发送数据时Adaptive Server遇到转换错误，它用ASCII码的问号（？）代替可疑字符所占字节，但查询批处理继续进行直到完成为止。
语句完成后，Adaptive Server将发送一下消息：
Msg 2403,Severity 16 (EX_USER):
WARNING! Some character(s) could not be converted into client's character set. Unconverted bytes were changed to question marks (`?')。
3. 当在客户端查询服务器端存储的数据时，当碰到中文汉字，在客户端显示乱码的现象，且没有任何提示信息。 这是我们在应用中经常会碰到的现象，产生的原因是：客户端与服务器端字符集不符。怎么解释呢？假设我们先期设置服务器端字符集为iso_1，客户端字符集也为iso_1,然后我们从客户端向服务器端录入了所有的数据；之后当我们需要查询时，使用的客户端，它的字符集为cp850，那么势必在该客户端上显示的字符集为乱码。
当出现这种情况时，最好配置客户端字符集为先期客户端使用的字符集或者配置客户端字符集与服务器端字符集一致，使得客户端字符集与服务器端字符集匹配。这里我们不建议用户修改服务器端字符集，因为服务器中此时已经存在大量的数据，在使用直接转换方式时，由于源字符集与目的字符集中可能存在无法转换的字符而导致Adaptive Server无法启动；如果使用间接的转换方式，会增加工作量。
4. 附：如何安装cp936字符集
以在Windows平台安装cp936字符集为例，说明如何安装使用服务器中没有被默认安装的字符集。(在ASE 12.5.0.3版本中安装GB18030字符集的方法类似)
(这里SYBASE的安装路径为c:\sybase)
1.c:\>;cd \sybase\charsets\cp936
2.c:\sybase\charsets\cp936>; charset -Usa -Psa_pass -Sserver_name binary.srt cp936
3.在SQL环境中 1>;select name,id from syscharsets
2>;go
找到name为cp936对应的id(假设为171)
4.1>;sp_configure "default character set id",171
2>;go
5.重启server两次
（注:第一次启动后，server会自动宕掉，需要第二次重启后才能使用）