1
我有以下更新查詢每晚運行,它將SQL空間數據庫(GIS)中的GIS信息更新到另一個數據庫(LIVE)。此更新在幾個月內一直沒有問題,並且突然間今天突然失效將數據類型從varchar轉換爲數字時出錯
「將數據類型從varchar轉換爲數字時出錯」。
update LIVE.dbo.PT001
Set
LIVE.dbo.pt001.dlonglegal_1 = Left(GIS.dbo.parcel.quartersection,2),
LIVE.dbo.pt001.dlonglegal_2 = SUBSTRING(GIS.dbo.parcel.quartersection,3,CHARINDEX('-',GIS.dbo.parcel.quartersection+'-')-3),
LIVE.dbo.pt001.dlonglegal_3 = SUBSTRING(GIS.dbo.parcel.quartersection,CHARINDEX('-',GIS.dbo.parcel.quartersection+'-')+1,1),
LIVE.dbo.pt001.dlonglegal_4 = SUBSTRING(GIS.dbo.parcel.quartersection,CHARINDEX('-',GIS.dbo.parcel.quartersection+'-')+3,1),
LIVE.dbo.pt001.dlonglegal_5 = right(GIS.dbo.parcel.quartersection,1)
From GIS.dbo.parcel inner Join
LIVE.dbo.PT001 on GIS.dbo.parcel.roll = LIVE.dbo.pt001.dROLLNMBR
where GIS.dbo.parcel.roll = LIVE.dbo.PT001.drollnmbr AND
GIS.dbo.parcel.quartersection is not null
的quartersection信息與以下格式存儲在包裹表作爲nvarchar的(30):
NW12-5-6E
在目標表中,將被存儲爲CHAR(15)和作爲如下:
dlonglegal_1 = NW
dlonglegal_2 = 12
dlonglegal_3 = 5
dlonglegal_4 = 6
dlonglegal_5 = E
我已經試過將數字字段作爲數字投射而沒有成功。我很難理解爲什麼更新今天開始失敗,因爲很長一段時間沒有對數據庫結構進行更改。
如果結構相同,那麼它可能是數據,如果你有像'NW12-5-6E'那樣會失敗的東西。 – artm
你在那裏做了一個從varchar到numeric的隱式轉換。我們不知道表結構,所以它只是猜測。它可能是dlonglegal專欄之一(那些looke像他們可以承受的那樣正常化,但這是另一個話題)。或者它可能是連接謂詞中的一個列。順便說一句,爲什麼在這個查詢中有一個where子句呢?返回的每一行都將始終符合該條件,因爲內部連接完全相同。 –
'roll'和'dROLLNMBR'有哪些類型?其中之一是數字和其他文字?如果是這樣,服務器將不得不將一列的值轉換爲另一列以執行連接。這也意味着性能已經受到影響,因爲此轉換可能會阻止優化器在文本列上使用索引 –