2(Вадим)

1С - это более чем не серьезно.
1С - это "подстава" для клиента
1С - это геморой для разработчика.

В 1С нет ни какого ядра (ни в 7 ни в 8). Это движок построения форм, модулей с возможностью юзать базу данных.

Ура! 1С умеет работать с SQL Server ... Ха! Вот это финт. Не умеет она этого и никогда не умела. 1С сумели кощунственно разместить DBF на SQL Server, а где же ЯДРО? Что умеет это "ЯДРО"? А ничего. Может это "ЯДРО" (не заряженное) умеет использовать хранимые процедуры? Или другие прелести SQL Server? Да ничего этого оно само не умеет. Есть вариант использовать ADO, но об этом позже.

Хотите пример. Вот, пожалуйста.

Есть устройство, которое сливает статистику. Мы нормализуем эту статистику на SQL Server (30 полей). Устройство это, сумасшедшее, льет по миллиону строк в месяц и это не предел. И чем (как) Вы, прошу прощения будете, из 1С это пользовать. А представьте, что это Ваши исходные данные - в них вся суть. Как теперь? А ни как.

1С, во-первых, видит с SQL Server только свои таблицы, созданные своим "великолепным" конфигуратором. Ну даже если предположить, что мы заранее создадим из конфигуратора таблицу и будем в нее лить статистику. Тут и напорешся на "Всемогущее ЯДРО" 1С, которое в лучшем случае позволит залить данные (если проигнорировать заполнение их (1С) специфичных полей, где они кодируют типы, связи и др.). Эту таблицу связать ни с кем нельзя (из того же конфигуратора) по той же причине, что не заполнены специфичные поля 1С - сразу "Ядро" вывалит ошибку и начнет переиндексировать (по-новому - восстанавливать структуру) таблицу. После восстановления "ЯДРО" опять таки все сделает по-своему.
SQL Server видет эти кощунства от конфигуратора. И даже может построить индексы, но попробуй построить составной индекс. Ха! Ошибка! После восстановления "ЯДРО" опять таки все сделает по-своему... Кому, извеняюсь, надо такое ядро?

Это "ЯДРО" доступается к SQL Server исключительно через пользвателя "SA" ни каких других учетных записей не признает. О Windows Autentification вообще в 1С никто не слышал.

Попробуй установить SQL Server на английский (язык), вот начнет мытарить душу "ЯДРО" о сортировке. И его не устроит переключение в Windows "язык и региональные стандарты" - надо будет SQL Server переинсталивать под русский, украинский или казахский, к примеру, язык. Вот Вам и ЯДРО...
Кроме того по моему примеру, таблица не будет соответствовать в точности к требованиям "Ядра" и естественно выполнить с данными всякого рода математику на прямую из 1С Вы не сможете. Надо будет организовывать какой-то экспорт. Вот и прийдется вам через встроенный язык напрягаться. А напрягаться прийдется с помощью ADO. С незначительными затратами времени Вы подключите ADO и даже сможете попробовать его юзать в 1С. И как только попытаетесть просканировать табличку в пару миллионов строк, так сразу же получите ошибочку TimeOut error (не помню точно, что-то в этом духе) и будете Вы над этой ошибочкой биться, вот только ни чего не добьетесь. Ударите шапкой о землю и задумаетесь - "Что же мне делать с этим ЯДРОМ дальше".

Так что можно сделать вывод - это "ЯДРО" просто расширило ограничения DBF за счет мощности SQL Server не меняя сути. С целью получения дополнительных доходов методом "навешивания лапши" о производительности и надежности - пользователям и программистам.

А на счет репортов - согласен, хорошо они (в 1С) организовали этот вопрос. Но извените, что Вы в этот прекрасный репорт будете сливать? Счет-фактуру? Надо же какая сложность для других репортов.

P.S. - по-моему, конфигуратор 1С и саму 1С в целом ни как нельзя назвать ядром по той причине, что любой и каждый с помощью того же конфигуратора, из кое как работающей проги может сделать что обезьяна с газетой, т.е. мотлох.
Считаю, что это абсолютно не устойчивая система. Которая требует огромных усилий для поддержки работоспособности, тех.сопровождения, обслуживания. Требует содержать штат программистов или пользоваться услугами сторонних разработчиков. И массу других недостатков.