Я использую SQLServer 2008 R2. У меня есть две таблицы, первая - таблица атрибутов. Второй имеет столбец, который ссылается на таблицу атрибутов. Две таблицы соединены с помощью столбца varchar(32).
#tblA #tblB
--------------------- ---------------------
attrib varchar(32) <---------> attrib varchar(32)
val nvarchar(255) [other fields]
[other fields]
Запрос объединяет таблицы и преобразует #tblA.val в int:
create table #tblA (attrib varchar(32), val nvarchar(255) /*, other fields */)
insert into #tblA values ('vase', 'red'), ('x', '323'), ('y', '615')
create table #tblB (attrib varchar(32) /*, other fields */)
insert into #tblB values ('x'), ('y')
select b.*, cast(a.val as int) as int_val
from #tblA a inner join #tblB b on a.attrib = b.attrib
drop table #tblB, #tblA
Этот пример работает:
attrib int_val
-------------------------------- -----------
x 323
y 615
Однако, когда я выполняю тот же запрос к своим производственным таблицам с тысячами записей, я получаю сообщение об ошибке: Ошибка преобразования при преобразовании значения nvarchar 'vase' в тип данных int.
Если я удалю cast() из производственного запроса, я увижу, что возвращенные данные для столбца val содержат только целочисленные значения.
Почему SQL Server пытается преобразовать значения, которые не являются частью возвращаемого набора данных? Еще более странно, если я включу a.val в список выбора в дополнение к cast(a.val as int), ошибок преобразования не будет. Кто-нибудь видел это раньше? Это просто ошибка в SQL Server?
Кстати, использование convert(int, a.val) имеет ту же проблему, что и cast(a.val as int).
select ... into #temp, затем делаюselect ..., cast(a.val as int) from #temp, и это работает. Таким образом, значения преобразуются правильно, если я сначала помещаю их в таблицу #temp, а затем выполняюcast(). Так что все данные верные. По какой-то причине SQL Server просто пытается преобразовать невозвращенные строки. Мне кажется, что это ошибка в SQL Server, но я решил опубликовать вопрос здесь, чтобы узнать, кто-нибудь видел это и знает, почему... - person James L.   schedule 19.10.2013