Здравствуйте, Sinix, Вы писали:

O>>Пока склоняюсь, что это ошибка производителя, других версий просто нет. Хотя причем здесь преобразование строки к числу, сортировка и какие-то ограничения на объем данных в редакции Enterprise ?!

S>Склоняюсь к "баг, воспроизводится в зависимости от плана".
S>Я бы взял скрипт на создание + планы в xml и закинул бы на http://dba.stackexchange.com/

S>UPD Вроде бы нашёл:
S>http://stackoverflow.com/questions/19018377/msg-8114-level-16-state-5-line-1-error-converting-data-type-varchar-to-numeri
S>http://stackoverflow.com/questions/17054604/msg-8114-level-16-state-5-line-1-error-converting-data-type-nvarchar-to-real

Спасибо. Еще раз окинул все свежим взглядом и вот что обнаружил. Ошибка не относится к редакции и другим ограничениям, а зависит от того какой план строит СУБД, все верно.

1. Во всех редакциях работает запрос, в котором используется стратегия соединения LOOP JOIN, но без сортировки, т.е.

select *
from dbo.Test1 t1 
left join dbo.Test2 t2 on t1.Name = t2.IdField
option(loop join)

С использованием HASH JOIN и MERGE JOIN возникает ошибка, причем во всех редакциях, но она в данном случае связана с механизмами построения результирующих данных.

2. Запрос с сортировкой вида…

select *
from dbo.Test1 t1 
left join dbo.Test2 t2 on t1.Name = t2.IdField
order by t1.SortOrder
option(loop join)

работает, только в том случае, если сначала идет сортировка, а потом выполняется неявное преобразование через Compute Scalar. Например, в Express редакции план выглядит так и запрос успешно выполняется



В Enterprise редакции, все наоборот, т.е. сначала выполняется неявное преобразование, а потом выполняется сортировка, причем сортировка выполняется по двум полям

a. [dbo].[Test1].SortOrder Ascending
б. Expr1006 Ascending = Scalar Operator(tertiary_weights([dbo].[Test1].[SortOrder] as [t1].[SortOrder]))



По факту получается к производителю никаких претензий, все в рамках функциональности.