隱蔽在SQLServer 字段中的超詭異字符處理進程。本站提示廣大學習愛好者：（隱蔽在SQLServer 字段中的超詭異字符處理進程）文章只能為提供參考，不一定能成為您想要的結果。以下是隱蔽在SQLServer 字段中的超詭異字符處理進程正文
文章作者：jhkdiy
揭橥日期：2009-10-11
法式架構：B/S
開辟情況：Windows XP + IIS6 + VS2003
數 據 庫：SQL Server 2000
部門功效：從 SQL Server 中導出數據到 Access。
這套體系做了年夜半年，這個導入導出照樣成績赓續，我擔任的這塊導入導出就是夾在網
絡版和單機版體系之間，只需任何一邊對數據庫做了修改這個導入導出就會掉敗。哎，煩心
的事不止這些，比來又碰到了一個異常奇異的成績。
因為之前的導入導出應用SQL Server 支撐的OpenDataSource（）函數來做，而當碰到
64位體系時就會碰到不支撐Microsoft.Jet.OLEDB.4.0 ，所以從新編碼，技巧步調是先從SQL Server 讀數據到DataTable，然後遍歷這個DataTable，對每行，將外面的數據從新組分解一條Insert 語句，然後翻開Access文件鏈接，履行適才生成的Insert語句，將數據拔出到Access中。
我終究提交給Access履行的語句是依據SQL Server中的數據拼出來，好比SQL Server ：select a, b, c from tblTemp
提交給Access履行的語句就是：
Str1 = “Insert into”
Str2 = “tblTemp(a,b,c)values(”
strResult = str1 & str2 & “‘aa', 2, ‘cc' ” & “)”
這回的嚴重成績是在SQL Server 表的b字段中有特別字符，此字符使我的法式沒法拼出完全的字符串，拼出來的字符串strResult 有時不帶最初的“)”，但奇異的是，這個表總共有4萬多筆記錄，只是組合個體記載才會湧現這個景象。然則提交給Access履行確定欠亨過，提醒SQL語法毛病。
我因而查詢數據庫的這筆記錄，用查詢剖析器查詢沒發明任何的特別字符，問了同過後才曉得，他說之前有過部門表中的某些字符保留了客戶輸出的回車換行符，我馬上年夜悟，對呀，回車換行符是看不見的啊，因而，想應用上面的語句查詢字段中能否有回車換行符：
select charindex(char(10), demc) from tblgc_jc_de where xh = 15641
select charindex(char(13), demc) from tblgc_jc_de where xh = 15641
select charindex(char(10) + char(13), demc) from tblgc_jc_de where xh = 15641
select charindex(char(13) + char(10), demc) from tblgc_jc_de where xh = 15641
但奇異的是，前往都是0，也就是找不到。這就愁悶了，字段中究竟存儲了甚麼字符啊？，另外一個同事教了一招，直接在企業治理器中前往該表的一切行記載，然後全選檢查該字段，發明確切是多出一個字符： 
不是回車換行符會是甚麼字符呢？在大惑不解之際，忽然想起，不如看看這個表物理數據，必定能查出存儲在該字段的是甚麼字符。然則該表有44022筆記錄，查某一筆記錄的物理數據就是年夜海撈針，怎樣辦？？？
我只想查詢這筆記錄的物理數據要怎樣做？能不克不及把這條數據放到另外一個表中，這個表只要這一筆記錄，這不便可以檢查了嗎。哦，這個簡略，其實我同時樹立了一個暫時的數據庫，這個數據庫只要一張表，這張表只要一筆記錄，就是包括下面誰人有成績的記載，應用的SQL語句以下：
-- TYZW 是正式庫
use TYZW
-- 創立一個暫時數據庫，然後將有成績的那條
-- 記載拔出暫時庫。
create database tmpTYZW
go
select * into tmpTYZW..tblgc_jc_de from tblgc_jc_de where xh = 15641
go
如今是時刻檢查一下這筆記錄的物理數據了，起首要在sysindexes體系表中查找出該表在物理文件中的地位，然後我們可以經由過程 dbcc page 敕令檢查物理數據：
接著應用dbcc page敕令檢查物理數據：
如今是時刻看看這筆記錄的物理數據了：
天啊，居然是0，真不知道是怎樣存出來的。成績終究曉得在那了，然則要若何處理呢？最簡略的辦法就是將這個0調換失落，因而應用以下語句測試：
select replace(demc, char(0), '') as demc from tblgc_jc_de
然則不可，緣由是replace函數找不到0這個字符，由於它查找是按兩個字節來找的，所以直接在SQL Server上找也找不到這個字符，調換也調換不了。然則，我又想了一下，能不克不及應用二進制來查找和調換？看了一下材料，應用上面的SQL語句能找出0在該字段的地位：
查是能查出來了，然則我發明replace函數照樣不克不及用，除非是調換4位，也就是0x0038。
最初其實無法，只能直接把有這個特別字符的地段截失落一個文字，也就是連誰人38也不要了：
select
case when charindex(convert(varbinary(1),0x00),convert(varbinary(200),demc)) > 0
then substring(demc,1,len(demc)-1)
else demc
end as DEMC
from tblgc_jc_de
這就是我如今用的終究處理計劃，由於我查詢過，4萬多筆記錄中只要8條有這個0在字段外面。所以就算截失落一個文字並影響法式的功效和顯示。
固然我如今寫出來許多步調看似走的很順，其實這個成績我用了幾地利間了，重要是找成績地點消耗了很多時光。如今給出此文願望寬大同伙在找這些成績時多個偏向，由於存儲在字段中的特別字符紛歧定就是慣例的回車換行符，也有能夠是其它字符，在此年夜家相互進修進步吧。
