Разыменования в коде (и прочее) - что при этом делает СУБД

Уже как несколько месяцев занимаемся укрупнением одной из наших информационных систем - переводим пользователей периферийных баз РБД на работу в общей базе данных. Такого вида деятельность предполагает дополнительные доработки для повышения масштабируемости ИС. Один и способов таких доработок - анализ тяжелых запросов. Собственно, вот, периодически занимаюсь таким анализом.

И вот "ради интереса" стали возникать вопросы - что же делает платформа на СУБД при выполнении каких-то операций. Вероятно, часть приведенных ниже результатов для кого-то будет далеко не новость (как и для меня). Но уж, простите, стараюсь раскопать тему насколько можно глубже и, главное, увидеть происходящее собственными глазами.

Тесты будем производить на демо-базе БСП 2.4 (версия 2.4.6.241), на платформе 1С:Предприятие 8.3 (8.3.10.2580), с использованием толстого обычного и тонкого клиентов, без RLS. Для возможности запуска тестовой обработки в обычном толстом клиенте, для конфигурации переключим Основной режим запуска - Обычное приложение. В тестовой внешней обработке добавим обычную форму, на ней разместим поле ввода с типом ДокументСсылка._ДемоЗаказПокупателя. Для тестирования будем добавлять кнопки с короткими обработчиками.

Вооружимся SQL Server Profiler. И поехали...

Классическое разыменование

Добавим кнопку с коротким обработчиком:

	Валюта = ЗаказСсылка.Валюта;
	Сообщить(Валюта.Наименование);

Выполнение второй строки (Сообщить(...)) вызывает полное вычитывание полей элемента.

SELECT
T2._IDRRef,
T2._Version,
T2._Marked,
T2._PredefinedID,
T2._Code,
T2._Description,
T2._Fld186,
T2._Fld182,
T2._Fld185,
T2._Fld184RRef,
T2._Fld183,
T2._Fld4322,
T2._Fld4323RRef,
T2._Fld2683
FROM dbo._Reference24 T2
WHERE ((T2._Fld2683 = @P1)) AND (T2._IDRRef = @P2 AND T2._Version <> @P3)

Ничего необычного, все ожидаемо. 

Представление элемента

	Валюта = ЗаказСсылка.Валюта;
	Сообщить(Строка(Валюта));

Уже интереснее. Выполнение второй строки (Сообщить(...)) вызывает вычитывание только Ссылки и Наименования элемента справочника.

SELECT
T1._IDRRef,
T1._Description
FROM dbo._Reference24 T1
WHERE ((T1._Fld2683 = @P1)) AND (T1._IDRRef = @P2)

Классическое разыменование сложного объекта

Под сложными имею в виду объекты, имеющие табличные части. Как раз, документ _ДемоЗаказПокупателя нам вполне подходит.

Разыменовываем номер документа:

Сообщить(Строка(ЗаказСсылка.Номер));

Получаем полное вычитывание документа - и реквизитов, и ТЧ (т.е., несколько запросов).

SELECT
T2._IDRRef,
T2._Version,
T2._Marked,
T2._Date_Time,
T2._Number,
T2._Posted,
T2._Fld3822,
T2._Fld5547,
T2._Fld2575RRef,
T2._Fld3825,
T2._Fld3827,
T2._Fld2909RRef,
T2._Fld3828,
T2._Fld1516,
T2._Fld6427RRef,
T2._Fld2908RRef,
T2._Fld968RRef,
T2._Fld4336RRef,
T2._Fld969RRef,
T2._Fld3824,
T2._Fld3821RRef,
T2._Fld3823_TYPE,
T2._Fld3823_S,
T2._Fld3823_RRRef,
T2._Fld2574,
T2._Fld6309,
T2._Fld2147,
T2._Fld6310RRef,
T2._Fld3826,
T2._Fld5548,
T2._Fld2683,
0 AS SDBL_IDENTITY
FROM dbo._Document39 T2
WHERE ((T2._Fld2683 = @P1)) AND (T2._IDRRef = @P2 AND T2._Version <> @P3)

SELECT
T3._LineNo971,
T3._Fld972RRef,
0 AS SDBL_IDENTITY
FROM dbo._Document39_VT970 T3
WHERE (T3._Document39_IDRRef = @P1) AND T3._Fld2683 = @P2
ORDER BY 3 ASC, T3._LineNo971

SELECT
T4._LineNo2149,
T4._Fld2150RRef,
T4._Fld2151RRef,
T4._Fld2152,
T4._Fld3662,
0 AS SDBL_IDENTITY
FROM dbo._Document39_VT2148 T4
WHERE (T4._Document39_IDRRef = @P1) AND T4._Fld2683 = @P2
ORDER BY 6 ASC, T4._LineNo2149

SELECT
T5._LineNo3664,
T5._Fld3665RRef,
T5._Fld3666RRef,
T5._Fld3667,
T5._Fld3668,
T5._Fld3669,
T5._Fld3670,
T5._Fld3671,
T5._Fld3672,
T5._Fld3673,
T5._Fld3674,
T5._Fld3675,
T5._Fld3676,
0 AS SDBL_IDENTITY
FROM dbo._Document39_VT3663 T5
WHERE (T5._Document39_IDRRef = @P1) AND T5._Fld2683 = @P2
ORDER BY 14 ASC, T5._LineNo3664

Хех, а хотелось бы - не обращаться к данным ТЧ без надобности. Читал, конечно, что платформа так не умеет. Но надежда теплилась - вдруг я чего-то пропустил, и в платформе появилось "чтение по требованию".

При разыменовании строки ТЧ, уже ожидаемо, вычитывается весь объект. Код:

Сообщить(ЗаказСсылка.СчетаНаОплату[0].Вид);

Представление сложного элемента

Выполним:

Сообщить(Строка(ЗаказСсылка));

Платформа генерит запрос на чтение Ссылки, Даты и Номера документа, без выборок ТЧ. Это уже ожидаемо. В условие выборки, кстати, еще докидывается отбор по разделителю области данных (T1._Fld2683 = @P1).

SELECT
T1._IDRRef,
T1._Number,
T1._Date_Time
FROM dbo._Document39 T1
WHERE ((T1._Fld2683 = @P1)) AND (T1._IDRRef = @P2)

Несколько вычитываний

Тут сюрпризов нет. Вычитывания вида (ниже) к повторам чтения на СУБД - не ведут.

	Сообщить("" + Валюта + Валюта);
	Сообщить("" + ЗаказСсылка.Номер + ЗаказСсылка.Договор);

Разве что, добавляются запросы для получения представлений ссылочных реквизитов (Договор, в нашем случае).

Выполнение инициализации объекта при разыменованиях

Закрались подозрения, что полное вычитывание является синонимом Ссылка.ПолучитьОбъект(). Однако, нет. Код инициализации объекта при разыменованиях НЕ выполняется.

"Зато" при полном вычитывании (в отличие от Ссылка.ПолучитьОбъект()) выполняется предварительный запрос получения последней версии объекта и полученное значение дополнительно участвует в отборе.

SELECT
T1._Version
FROM dbo._Document39 T1
WHERE ((T1._Fld2683 = @P1)) AND (T1._IDRRef = @P2)

SELECT
T2._IDRRef,
T2._Version,
T2._Marked,
T2._Date_Time,
T2._Number,
T2._Posted,
T2._Fld3822,
T2._Fld5547,
T2._Fld2575RRef,
T2._Fld3825,
T2._Fld3827,
T2._Fld2909RRef,
T2._Fld3828,
T2._Fld1516,
T2._Fld6427RRef,
T2._Fld2908RRef,
T2._Fld968RRef,
T2._Fld4336RRef,
T2._Fld969RRef,
T2._Fld3824,
T2._Fld3821RRef,
T2._Fld3823_TYPE,
T2._Fld3823_S,
T2._Fld3823_RRRef,
T2._Fld2574,
T2._Fld6309,
T2._Fld2147,
T2._Fld6310RRef,
T2._Fld3826,
T2._Fld5548,
T2._Fld2683,
0 AS SDBL_IDENTITY
FROM dbo._Document39 T2
WHERE ((T2._Fld2683 = @P1)) AND (T2._IDRRef = @P2 AND T2._Version <> @P3)

Открытие управляемой формы

В тестовой обработке создадим дополнительную управляемую форму с основным реквизитом ДокументОбъект._ДемоЗаказПокупателя. И посмотрим, что будет происходить при открытии управляемой формы документа.

А происходит вот что.

• Полное вычитывание всех реквизитов документа и его ТЧ. Ну это ожидаемо.
• Для всех ссылочных реквизитов самого документа (не ТЧ) выполняется несколько коротких запросов для получения представлений ссылок. В принципе, тоже ожидаемо. 
• Для ссылочных реквизитов ТЧ выполняются запросы вида: 

  SELECT
  T1._IDRRef,
  T1._Description
  FROM dbo._Reference33 T1
  WHERE ((T1._Fld2683 = @P1)) AND ((T1._IDRRef IN (@P2, @P3)))
  ORDER BY T1._IDRRef

  где @P2, @P3 - перечисление ссылок какого-то ссылочного поля ТЧ, без дублей. Причем, для ТЧ проверка IN (@...) конструируется и для случаев, когда нужно получить представление только для одной ссылки (т.е., без замены на "=").

Открытие обычной формы объекта с ТЧ

Мда, это ахтунг и источник массы запросов с получением представлений.

На каждую строку может "пуляться" несколько запросов - в зависимости от того, сколько выводится ссылочных полей. Справедливости ради, запросы для получения представлений ссылок кешируются.

Сделали выводы, переделываем... В формах, где может быть потенциально много строк ТЧ, скрыли стандартные ссылочные поля. Их представления получаем разом и помещаем в соответствие. Полученные текстовки выводим в специально добавленные колонки ТЧ.

Журналы документов

Вывод списка журнала документов и послужил началом для моих экспериментов. А все потому что в топе запросов, нагружающих процессор, был запрос вида:

SELECT 
[Список полей]
FROM dbo._DocumentJournal836 T1
LEFT OUTER JOIN dbo._Reference16 T2
ON (T1._Fld838RRef = T2._IDRRef) AND (T2._Fld2683 = @P1)
LEFT OUTER JOIN dbo._Reference33 T3
ON (T1._Fld840RRef = T3._IDRRef) AND (T3._Fld2683 = @P2)
LEFT OUTER JOIN dbo._Reference16 T4
ON (T1._Fld839RRef = T4._IDRRef) AND (T4._Fld2683 = @P3)
LEFT OUTER JOIN dbo._Reference19 T5
ON (T1._Fld837RRef = T5._IDRRef) AND (T5._Fld2683 = @P4)
LEFT OUTER JOIN dbo._Document581 T6
ON (T1._DocumentTRef = 0x00000245 AND T1._DocumentRRef = T6._IDRRef) AND (T6._Fld2683 = @P5)
LEFT OUTER JOIN dbo._Document579 T7
ON (T1._DocumentTRef = 0x00000243 AND T1._DocumentRRef = T7._IDRRef) AND (T7._Fld2683 = @P6)
LEFT OUTER JOIN dbo._Document578 T8
ON (T1._DocumentTRef = 0x00000242 AND T1._DocumentRRef = T8._IDRRef) AND (T8._Fld2683 = @P7)
WHERE ((T1._Fld2683 = @P8)) AND (((T6._Fld803RRef = @P9 OR T7._Fld679RRef = @P10 OR T8._Fld667RRef = @P11)))
ORDER BY T1._Date_Time, T1._DocumentTRef, T1._DocumentRRef

SELECT
T1._Date_Time,
T1._Posted,
T1._Marked,
T1._Fld4346,
T1._Fld838RRef,
T1._Fld840RRef,
T1._Fld839RRef,
T1._Fld837RRef,
T1._DocumentTRef,
T1._DocumentRRef,
T2._Description,
T3._Description,
T4._Description,
T5._Description
FROM dbo._DocumentJournal836 T1
LEFT OUTER JOIN dbo._Reference16 T2
ON (T1._Fld838RRef = T2._IDRRef) AND (T2._Fld2683 = @P1)
LEFT OUTER JOIN dbo._Reference33 T3
ON (T1._Fld840RRef = T3._IDRRef) AND (T3._Fld2683 = @P2)
LEFT OUTER JOIN dbo._Reference16 T4
ON (T1._Fld839RRef = T4._IDRRef) AND (T4._Fld2683 = @P3)
LEFT OUTER JOIN dbo._Reference19 T5
ON (T1._Fld837RRef = T5._IDRRef) AND (T5._Fld2683 = @P4)
LEFT OUTER JOIN dbo._Document581 T6
ON (T1._DocumentTRef = 0x00000245 AND T1._DocumentRRef = T6._IDRRef) AND (T6._Fld2683 = @P5)
LEFT OUTER JOIN dbo._Document579 T7
ON (T1._DocumentTRef = 0x00000243 AND T1._DocumentRRef = T7._IDRRef) AND (T7._Fld2683 = @P6)
LEFT OUTER JOIN dbo._Document578 T8
ON (T1._DocumentTRef = 0x00000242 AND T1._DocumentRRef = T8._IDRRef) AND (T8._Fld2683 = @P7)
WHERE ((T1._Fld2683 = @P8)) AND (((T6._Fld803RRef = @P9 OR T7._Fld679RRef = @P10 OR T8._Fld667RRef = @P11)))
ORDER BY T1._Date_Time, T1._DocumentTRef, T1._DocumentRRef

Сразу обозначу, что это происходило для списка журнала документов в обычном приложении и обычной (неуправляемой) форме. В этой форме, при открытии, сразу накладывался отбор по полю журнала.

Т.е., помимо ожидаемых соединений со справочниками для представлений ссылок, в запросе еще присутствуют соединения с документами журнала. А еще какое "красивое" условие в секции WHERE/ГДЕ...

Для подготовки статьи, в тестовую обработку быстро добавил обычную форму журнала, сделал возможность отборов и стал отлавливать запрос в профайлере. К моему удивлению, запрос был чист от таких непонятно откуда взятых конструкций.

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

Выборка данных

Посмотрим, что происходит на СУБД при выполнении метода МенеджерОбъекта.Выбрать(...). Для примера будем использовать справочник КлючевыеОперации.

А происходит следующее. Данные вычитываются частями с использованием TOP 25.

SELECT TOP 25
T1._IDRRef,
T1._Version,
T1._Marked,
T1._PredefinedID,
T1._Description,
T1._Fld4266,
T1._Fld2644RRef,
T1._Fld2645,
T1._Fld2646,
T1._Fld5283,
T1._Fld5921,
T1._Fld6495
FROM dbo._Reference2598 T1
ORDER BY (T1._Description) ASC, (T1._IDRRef) ASC

SELECT TOP 25
T1._IDRRef,
T1._Version,
T1._Marked,
T1._PredefinedID,
T1._Description,
T1._Fld4266,
T1._Fld2644RRef,
T1._Fld2645,
T1._Fld2646,
T1._Fld5283,
T1._Fld5921,
T1._Fld6495
FROM dbo._Reference2598 T1
WHERE T1._Description = @P1 AND T1._IDRRef > @P2
ORDER BY (T1._Description) ASC, (T1._IDRRef) ASC
OPTION (FAST 1)

ПРЕДСТАВЛЕНИЕ и ПРЕДСТАВЛЕНИЕССЫЛКИ (из языка запросов)

Посмотрим, как использование функций ПРЕДСТАВЛЕНИЕ и ПРЕДСТАВЛЕНИЕССЫЛКИ языка запросов выражается в конечном запросе СУБД. Используем такой вот запрос:

ВЫБРАТЬ
	Пользователи.Ссылка КАК Ссылка,
	Пользователи.Наименование КАК Наименование,
	Пользователи.Недействителен КАК Недействителен,
	"ПРЕДСТАВЛЕНИЕ(Пользователи.Ссылка)" КАК Поле1,
	ПРЕДСТАВЛЕНИЕ(Пользователи.Ссылка) КАК СсылкаПредставление,
	"ПРЕДСТАВЛЕНИЕ(Пользователи.Комментарий)" КАК Поле2,
	ПРЕДСТАВЛЕНИЕ(Пользователи.Комментарий) КАК КомментарийПредставление1,
	"ПРЕДСТАВЛЕНИЕССЫЛКИ(Пользователи.ФизическоеЛицо)" КАК Поле3,
	ПРЕДСТАВЛЕНИЕССЫЛКИ(Пользователи.ФизическоеЛицо) КАК ФизическоеЛицоПредставление,
	"ПРЕДСТАВЛЕНИЕССЫЛКИ(Пользователи.Комментарий)" КАК Поле4,
	ПРЕДСТАВЛЕНИЕССЫЛКИ(Пользователи.Комментарий) КАК КомментарийПредставление
ИЗ
	Справочник.Пользователи КАК Пользователи

Его выполнение на СУБД выглядит так:

SELECT
T1._IDRRef,
T1._Description,
T1._Fld2407,
@P1, // "ПРЕДСТАВЛЕНИЕ(Пользователи.Ссылка)"
T1._IDRRef,
T2._Description,
@P2, // "ПРЕДСТАВЛЕНИЕ(Пользователи.Комментарий)"
T1._Fld4184,
@P3, // "ПРЕДСТАВЛЕНИЕССЫЛКИ(Пользователи.ФизическоеЛицо)"
T1._Fld5058RRef,
T3._Description,
@P4, // "ПРЕДСТАВЛЕНИЕССЫЛКИ(Пользователи.Комментарий)"
T1._Fld4184
FROM dbo._Reference33 T1
LEFT OUTER JOIN dbo._Reference33 T2
ON (T1._IDRRef = T2._IDRRef) AND (T2._Fld2683 = @P5)
LEFT OUTER JOIN dbo._Reference38 T3
ON (T1._Fld5058RRef = T3._IDRRef) AND (T3._Fld2683 = @P6)
WHERE (T1._Fld2683 = @P7)

ВЫБРАТЬ
T1._Ссылка,
T1._Наименование,
T1.Недействителен,
@P1, // "ПРЕДСТАВЛЕНИЕ(Пользователи.Ссылка)" 
T1._Ссылка,
T2._Наименование,
@P2, // "ПРЕДСТАВЛЕНИЕ(Пользователи.Комментарий)"
T1.Комментарий,
@P3, // "ПРЕДСТАВЛЕНИЕССЫЛКИ(Пользователи.ФизическоеЛицо)"
T1.ФизическоеЛицо,
T3._Наименование,
@P4, // "ПРЕДСТАВЛЕНИЕССЫЛКИ(Пользователи.Комментарий)"
T1.Комментарий
ИЗ dbo.Справочник.Пользователи T1
ЛЕВОЕ СОЕДИНЕНИЕ dbo.Справочник.Пользователи T2
ПО (T1._Ссылка = T2._Ссылка) И (T2.ОбластьДанныхОсновныеДанные = @P5)
ЛЕВОЕ СОЕДИНЕНИЕ dbo.Справочник._ДемоФизическиеЛица T3
ПО (T1.ФизическоеЛицо = T3._Ссылка) И (T3.ОбластьДанныхОсновныеДанные = @P6)
ГДЕ (T1.ОбластьДанныхОсновныеДанные = @P7)

А теперь попробуем поработать с полями составного типа. Возьмем регистр сведений ДополнительныеСведения, добавим в него запись со значением поля Свойство - ссылка на элемент справочника _ДемоПартнеры. Используем такой вот запрос:

ВЫБРАТЬ
	ПРЕДСТАВЛЕНИЕ(ДополнительныеСведения.Значение) КАК Значение1
ИЗ
	РегистрСведений.ДополнительныеСведения КАК ДополнительныеСведения

На выходе получаем два запроса - плоский запрос ко всем возможным полям свойства (оно ведь составное). И для получения представления выполняется еще один запрос, сходный с тем, которые используются для представлений ссылок ТЧ (см.выше).

SELECT
T1._Fld448_TYPE,
T1._Fld448_L,
T1._Fld448_N,
T1._Fld448_T,
T1._Fld448_S,
T1._Fld448_RTRef,
T1._Fld448_RRRef
FROM dbo._InfoRg445 T1
WHERE (T1._Fld2683 = @P1)

SELECT
T1._IDRRef,
T1._Description
FROM dbo._Reference20 T1
WHERE ((T1._Fld2683 = @P1)) AND ((T1._IDRRef IN (@P2)))
ORDER BY T1._IDRRef

ВЫБРАТЬ
T1.Значение,
T1.Значение,
T1.Значение,
T1.Значение,
T1.Значение,
T1.Значение,
T1.Значение
ИЗ dbo.РегистрСведений.ДополнительныеСведения T1
ГДЕ (T1.ОбластьДанныхОсновныеДанные = @P1)

ВЫБРАТЬ
T1._Ссылка,
T1._Наименование
ИЗ dbo.Справочник._ДемоПартнеры T1
ГДЕ ((T1.ОбластьДанныхОсновныеДанные = @P1)) И ((T1._Ссылка В (@P2)))
УПОРЯДОЧИТЬ ПО T1._Ссылка

Собственно, вот и ответ - почему ПРЕДСТАВЛЕНИЕ не является обычной строкой для манипуляций в языке запросов 1С. В основном запросе нет никаких соединений со справочником _ДемоПартнеры для получения каких-то текстовок, нет конструкций с использованием ISNULL(...) или CASE. Наше ПРЕДСТАВЛЕНИЕ вычисляется в результате пост-обработки результатов запросов уже на стороне платформы.

КОНЕЦПЕРИОДА (из языка запросов)

Итоговая конструкция функции КОНЕЦПЕРИОДА(&Дата, День) выглядит так:

DATEADD(SECOND,@P3,DATEADD(MINUTE,@P4,DATEADD(HOUR,@P5,DATEADD(DAY,CAST(DATEPART(DAY,@P6) КАК NUMERIC(4)) - 1,DATEADD(MONTH,CAST(DATEPART(MONTH,@P7) КАК NUMERIC(4)) - 1,DATEADD(YEAR,CAST(DATEPART(YEAR,@P8) КАК NUMERIC(4)) - 2000,@P9)))))))

Мда, несколько монструозно. Видим примерно следующую логику: к дате 01.01.2000 добавляются составляющие года (минус 2000), месяца и дня из переданной даты, и добавляется время 23:59:59. 

Заключение

На текущий момент исследования трансляции работы механизмов платформы на СУБД - закончены. Полученные сведения, конечно, не перевернули картину мира:) Но все-таки было достаточно интересно покопаться в деталях.

Часть 2

Часть экспериментов повторим на 8.3.16.1063.

В качестве пациента - простая самописка "с нуля". Буду докидывать к нее что-то по необходимости. Изначально сделал в ней 2 справочника - плоский и с ТЧ (одно из полей ТЧ ссылается на плоский справочник). И тестовая обработка, где буду размещать тестовый код.

Классическое разыменование

Сообщить(ЭлементыСправочника1[0].Наименование);

Такой вот код, во всех подробностях. Потом будет короче:)

&НаКлиенте
Процедура ВычитатьНаименованиеПлоскогоСправочника(Команда)
	ВычитатьНаименованиеПлоскогоСправочникаНаСервере();
КонецПроцедуры

&НаСервереБезКонтекста
Процедура ВычитатьНаименованиеПлоскогоСправочникаНаСервере()
	
	ЭлементыСправочника1 = ЭлементыСправочника("СправочникПлоский1");
	Сообщить(ЭлементыСправочника1[0].Наименование);  // Тестовый код
	
КонецПроцедуры

&НаСервереБезКонтекста
Функция ЭлементыСправочника(ИмяСправочника)
	
	Запрос = Новый Запрос;
	Запрос.Текст = СтрШаблон("ВЫБРАТЬ Ссылка из Справочник.%1", ИмяСправочника);
	
	Результат = Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку(0);
	Возврат Результат;
	
КонецФункции

Разыменование Наименования, как и прежде, приводит к вычитыванию всего элемента.

exec sp_executesql N'SELECT
T1._IDRRef,
T1._Version,
T1._Marked,
T1._PredefinedID,
T1._Code,
T1._Description,
T1._Fld40, -- это добавленный реквизит справочника
T1._Fld41  -- это добавленный реквизит справочника
FROM dbo._Reference31 T1
WHERE T1._IDRRef = @P1',N'@P1 varbinary(16)',0x80CA0A94EF7B6CE711EA258395D83033

Классическое разыменование сложного объекта

Тестовый код - такой же, как и выше. Только уже используются ссылки другого справочника.

Разыменование, как и прежде, вычитывает данные и из основной таблицы, и из таблицы ТЧ.

exec sp_executesql N'SELECT
T1._IDRRef,
T1._Version,
T1._Marked,
T1._PredefinedID,
T1._Code,
T1._Description,
T1._Fld42,
0 AS SDBL_IDENTITY
FROM dbo._Reference35 T1
WHERE T1._IDRRef = @P1',N'@P1 varbinary(16)',0x80CA0A94EF7B6CE711EA2583CBCBC694
go
exec sp_executesql N'SELECT
T2._LineNo37,
T2._Fld38,
T2._Fld39RRef,
0 AS SDBL_IDENTITY
FROM dbo._Reference35_VT36 T2
WHERE T2._Reference35_IDRRef = @P1
ORDER BY 4 ASC, T2._LineNo37',N'@P1 varbinary(16)',0x80CA0A94EF7B6CE711EA2583CBCBC694
go

Заключение по части 2

Что-то дальше смотреть для 8.3.16 - пока не вижу смысла/цели.