类似HIS的,需要我这边说明什么环境?服务器是SERVICE2003,X86,4G内存,在SQL2000企业版基础上直接升级2005企业版,客户机环境是XP,2G内存和WIN7,2G内存,环境不动的情况下SQL2000没问题,升级2005就不行.以上都是简体中文的系统

解决方案 »

  1.   


    这个是服务器现在的运行环境,无任何乱码问题:这个是升级后的SQL2005:还需要帖什么运行环境老大?
      

  2.   

    看上去没问题,使用了ntext但是没用N来插入数据,可见这个软件提供商的水平或者责任感相当差。另外你是不是用profiler抓出会出现的乱码都是基于ntext数据的?
      

  3.   

    软件商在数据库里用的全是text,没有ntext,软件是按照2000的环境做的,貌似vchat都很少,随便翻了下,只要是储存文字,全是text的.但是我和软件商沟通过,他们说别的医院没有反应过这个情况,而且问题在他们那没有复现,但是我让他们改语句的时候他们就不干了,说工作量太大(应该是SQL语句都集成在程序里了),所以实在没招,现在生产环境还在用sql2000呢~
      

  4.   

    那你用profiler抓到发生乱码的地方语句是如何的?
      

  5.   

    “异?改”,“常”字太普通了,不可能转换不出来的,在异和改之间的“常”字,可能有一些看不见的ASCII码。
      

  6.   

    UPDATE JLB SET JCJG='【9. 红细胞平均血红蛋白浓度降低】
        本次检验结果异?改变较小,建议您隔期复查血常规。',TYDL=NULL,ZLJY=NULL WHERE StudyID='1305181337' AND JLDM IS NULL  AND JLRQ='20130702 15:30:55.216' AND JLYS='任红美' AND ZJYS='李延知' AND ZJRQ='20130703 09:25:13.000' AND AuditTag IS NULL  AND PGJG IS NULL  AND CompareKS IS NULL  AND CompareID1 IS NULL  AND CompareID2 IS NULL  AND CompareID3 IS NULL抓到的就是这个,用不用贴出来抓到的上下的语句?貌似这个就是用update命令更改了一下,出问题后我用查询分析器手动输入汉字更改就没问题,而且客户机环境不变的情况下,在服务器这边server2003+SQL2000怎么折腾都不会有问题,profiler抓到的也是正常的,服务端的SQL无论是升级2005或者全新安装2005和2008,都有这个问题存在,而且貌似发现就是那么几个字容易出现?,还有一次抓到的是'■'这个,但是就抓到一次,后面抓到的都是'?'
      

  7.   

    从描述上来说,感觉是应用程序的问题,如果你有空并且有条件,装个新的SQL Server 2005,然后把你的库中数据清空,仅保留结构,再用你的程序去操作一下看看会不会乱码
      

  8.   


    你升级2005的字段类型是text,还是ntext?升级前SQL2000对应的字段类型是什么。
      

  9.   


    你升级2005的字段类型是text,还是ntext?升级前SQL2000对应的字段类型是什么。
    都是text类型
      

  10.   


    说明你使用的操作系统都是简体中文版本。你运行的脚本在NotePad一类的文本编辑器中打开,是否能正常显示,如果显示正常,那么可用采用osql一类的工具导入数据。
      

  11.   

    如果记事本能正常打开,用Unicode编码另存为,就不会有默认编码不一致的问题了。
      

  12.   

    如果清空了都还这样,那应用程序端的问题比较严重,你可以再次测试一下,就在你这个测试库中,把相关字段改成ntext试试
      

  13.   


    也许他的应用程序代码无法转换成文本文件。
    恩,这个程序很闹心.当初不是我接手的,不太了解情况,总之后期BUG太多了
      

  14.   

     是的,他们的那个软件开发商大手子已经去外国单干了,剩下的职员只能修补修补BUG什么的,开发大的功能基本不行了,我们这边4年的数据全在里面,已经换不了了...谢谢老大了!
      

  15.   


    用select语句计算一下?的个数,如果不多可以手工改改,更完美的解决方法暂时找不到了。
      

  16.   

    也许他的应用程序代码无法转换成文本文件。
    恩,这个程序很闹心.当初不是我接手的,不太了解情况,总之后期BUG太多了
    我的意思是升级时的数据(插入数据的SQL脚本或导入的数据文本用Unicode)。又:“升级”时怎么会把 Text 类型变成 NText 的?
    即没有程序的同步升级,又没有存放多国语言文本的需求,保留原数据类型就好了!
      

  17.   


    问题是记事本不能正常打开应用程序,所以无法另存为Unicode编码。
      

  18.   


    用select语句计算一下?的个数,如果不多可以手工改改,更完美的解决方法暂时找不到了。之前数据库升级到2005的时候我就是这么干的,但是工作量太大,我们这每天的体检量淡季100多,旺季最多500左右人,按照报告每天生成400份算,就是出现一半也得有200左右报告需要改,再加上我只是管理网络的,有些?我能改,比如乙肝两对半全? 我能猜到是全阴,但是别的不一定知道是什么字,毕竟不是学医的,很多情况都得问医生,要是处理的时间慢了,可能报告就发出去了.这个办法不可行(我印象中300人体检的时候我搜出来100多份带?的)后来没办法,把数据库又降到2000了
      

  19.   


    也许他的应用程序代码无法转换成文本文件。
    恩,这个程序很闹心.当初不是我接手的,不太了解情况,总之后期BUG太多了
    我的意思是升级时的数据(插入数据的SQL脚本或导入的数据文本用Unicode)。又:“升级”时怎么会把 Text 类型变成 NText 的?
    即没有程序的同步升级,又没有存放多国语言文本的需求,保留原数据类型就好了!
    但是程序再插入的时候数据库也会形成?的
      

  20.   

    做一个大胆的假设,如果先把Sql2000中的Text类型升级为nText类型,再将2005中的类型定义为nText,升级2000数据库会不会有变化。
      

  21.   

    因为程序里是用 '异常'  而不是 N'异常' ,所以你的 SQL Server 2005 数据库应该继续用 Text 类型,别想 NText 类型了!
      

  22.   

    因为程序里是用 '异常'  而不是 N'异常' ,所以你的 SQL Server 2005 数据库应该继续用 Text 类型,别想 NText 类型了!不可啊,语句集成在程序里,换成ntext程序报错
      

  23.   

    因为程序里是用 '异常'  而不是 N'异常' ,所以你的 SQL Server 2005 数据库应该继续用 Text 类型,别想 NText 类型了!是的,这个方法确实不行,升级前text升级后也得是text,要不程序报错,但正因为如此,所以出?是必然了
      

  24.   

    Unicode 数据使用 SQL Server 中的 nchar、varchar 和 ntext 数据类型进行存储。对于存储来源于多种字符集的字符的列,可采用这些数据类型。当列中各项所包含的 Unicode 字符数不同时(至多为 4000),使用 nvarchar 类型。当列中各项为同一固定长度时(至多为 4000 个 Unicode 字符),使用 nchar 类型。当列中任意项超过 4000 个 Unicode字符时,使用 ntext 类型。
    在 Microsoft SQL Server 2000 中,传统上非 Unicode 数据类型允许使用由特定字符集定义的字符。字符集是在安装 SQL Server 时选择的,不能更改。使用 非Unicode 数据类型存储数据时,如varchar, char, text等,如果未指定字符排序序列时(字符集),使用默认的字符集,即使为某个字段指定了字符排序序列时,如果SQL Server 默认的排序序列与指定字段的排序序列不同时,不加N的话也会产生乱码,如默认的字符集是单字节的字符集如拉丁字符集(Collation name为Latin1_General_CI_AS)的时候,如果定义Name为Varchar类型,字符集为中文字符集时(Collation name为Chinese_PRC_CI_AS),用如下的插入语句也会乱码
    insert a(name) values ('AA中'),因为数据插入的时候,默认还是用Latin1_General_CI_AS字符集送到服务器,再转换为Collation name为Chinese_PRC_CI_AS时,产生乱码,但如果改为如下的时候: insert a(name) values (N'AA中') 则能正确插入,因为通过N前缀,以UNICODE的形式送到SQLSERVER,然后再转换成Chinese_PRC_CI_AS时,就不会产生乱码。
      

  25.   

    UNICODE--〉非UNICODE:
    Convert(varchar(50), name Collate Chinese_PRC_CS_AS_KS_WS)--name 是nvarvhar类型的,如name是'AA中'的时候;非UNICODE--〉UNICODE的时候:
    Convert(nvarchar(50), name)--name是varchar类型的时候,如name是'AA中'的时候。
      

  26.   

    文字显示问题
    1. N''要和数据类型nvarchar, nchar一起使用,如果对varchar, char字段类型强制使用N'',则会产生一些特殊现象,甚至无法控制; 
    2. 在英文字符集下,想要保存特殊符号字符、中文等双字节字符,在定义表结构时要使用nvarchar或者nchar,在保存时要用N'';
    3. 在中文字符集下,数据库系统缺省已经可以保存特殊符号字符、中文等双字节字符。即使用不使用N'',都按双字节处理。
    但为了统一期间建议:
    在定义表结构时如果使用nvarchar或者nchar,在保存时要用N'',
    在定义表结构时如果使用varchar和char,此时不要使用N''操作;
    4. SUBSTRING ( expression , start , length ) 
    length:是一个整数,指定子串的长度(要返回的字符数或字节数)。
    中文字符集中按字符数取;
    英文字符集中,char, varchar按字节数取,nchar, nvarchar按字符数取;
      

  27.   

    37楼说到默认字符集是关键!A)更改数据库的默认字符集为中文。
    好像没法改,要重建数据库了。B)设置数据库连接的默认字符集为中文。
    直接在 ConnectionString 中指定的方式没用过,不过设置系统 DNS 时是可以设置的。
    如果程序写的好,有配置文件的话,就是改下配置的工作量。
      

  28.   

    A)就是生成建表脚本,删数据库,建数据库(设默认字符集),执行脚本。
    最好从原2000数据库生成脚本,否则得批量替换 NText 为 Text 了。B)这个可以咨询一下,通常是动态配置的,即使是改程序也是一个字符串常量而已。
    难道这个系统只有一个服务器?
    那么服务器硬件故障时就没有后备服务器顶上了!
    有后备服务器的应该有动态配置,否则两服务器必须有相同的名称或IP,不利与数据同步。
      

  29.   

    A)就是生成建表脚本,删数据库,建数据库(设默认字符集),执行脚本。
    最好从原2000数据库生成脚本,否则得批量替换 NText 为 Text 了。B)这个可以咨询一下,通常是动态配置的,即使是改程序也是一个字符串常量而已。
    难道这个系统只有一个服务器?
    那么服务器硬件故障时就没有后备服务器顶上了!
    有后备服务器的应该有动态配置,否则两服务器必须有相同的名称或IP,不利与数据同步。确实只有一个服务器,而且这个服务器也是3年前的,没有升级硬件,磁盘是RAID5,每天执行自动备份到FTP上,仅此而已,因为每年的服务费我们单位并没有交,所以3年左右软件供应商一直没给我们做任何维护,一直是我在维护索引和服务器的性能或者日常维护,仅此而已.