【发布时间】:2015-05-14 13:25:19
【问题描述】:
我每晚运行以下更新查询,它将 SQL 空间数据库 (GIS) 中的 GIS 信息更新到另一个数据库 (LIVE)。此更新已经运行了几个月没有问题,但今天突然失败了
“将数据类型从 varchar 转换为 numeric 时出错。”
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
四分之一部分信息以 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' 的东西就会失败。
-
你有一些东西正在执行从 varchar 到 numeric 的隐式转换。我们不知道表结构,所以只是猜测。它可能是 dlonglegal 专栏之一(那些看起来像是可以忍受标准化但那是另一个话题)。或者它可能是您的连接谓词中的列之一。顺便说一句,为什么这个查询中有一个 where 子句?返回的每一行都将始终满足该条件,因为内部连接完全相同。
-
roll和dROLLNMBR有哪些类型?其中一个是数字,另一个是文本吗?如果是这样,服务器必须将一列的值转换为另一列才能执行连接。这也意味着性能已经受到影响,因为这种转换可能会阻止优化器在文本列上使用索引 -
我的建议是检查 dlonglegal 列的精度。如果您期望 NW12-5-6E 并且您实际上有 NW12-55-6E 它会弄乱整个子字符串。也许做一个 TRY_CONVERT 然后寻找 NULLS?
标签: sql-server sql-server-2012