amakhinВо-первых не хочет понимать соединение через where, когда меняю на inner join всё работает, вычитал, что вроде должно лечится через настройку tsql_outer_joins - не лечится.

Во-вторых матюкается на null value в аггрегатной функции, но это как раз точно лечится через allow_nulls_by_default, но в связи с этим вопрос можно ли как то эту настройку указать в командной строчке при запуске сервера?

1. Бред. Что значит не хочет понимать. Приведите текст запроса и ответ сервера.
2. Это вроде от того, что клиента используете старого. Сервак шлет предупреждение. Девяточный клиент нормально их обрабатывает, те клиенты, которые ниже версией, выводят его как ошибку. Уже писал когда-то на форуме, могли бы в поиске найти.

amakhin,

1. Не держите людей за дураков. Я не просто так написал приведите текст запроса. На Ваш запрос мой сервер выдает ошибку "Syntax error near '.' on line 1". Уверяю, что соединение таблиц через WHERE в 9-ке работает на ура. И чтобы Вас ткнуть носом нужен полный текст запроса, а не Ваша интерпретация его.
Illegal reference к примеру может означать, что Вы пытаетесь в условии по левому соединению table3 использовать поля из table1. Это говорит только о некорректности написания запроса, и то, что он работал раньше где-то, говорит скорее о фичи/баге той версии, чем о недоработке в этой. Старый оптимизатор не видел двусмысленности и глотал все что суют, а новый - видит. Писать запросы изначально нужно корректно, по стандарту, и никаких проблем не будет.

2. Под клиентом я подразумевал именно драйвер, установленный на клиенте(в случае ODBC соединения). Нужно глядеть его версию. Вы написали, что там у Вас грабли. Грабли, я понимаю как нарушение алгоритмики работы имеющегося ПО. Так вот, если Ваша программа спокойно работает и ничего не видит, то не вижу проблем. Если же Ваша программа встает в раскоряку из-за неспособности драйвера корректно обработать эту ситуацию, то обновите сабейзовского клиента, тогда в Вашей программе не будет нарушена алгоритмика работы, и после запроса она не будет уходить в исключение.
Если трогать "allow_nulls_by_default", то это может аукнуться совершенно в другой степи, т.к. 9-ка и 6/7/8-ка по умолчанию работают одинаково, а вот с этой опцией 9-ка будет работать уже не как 6/7/8-ка.

amakhiniLLer,
вы правы, если я меняю местами таблицы, то начинает работать. Но до сих пор не совсем понимаю какое имеет значение порядок таблиц в from.

Судя по запросу, там именно то, что я и предположил. Проблема в том, что использование левого соединения подразумевает что в его условии используются только поля из соединяемых таблиц. Ссылаясь в условии левого соединения на третью свободную таблицу (t), сервер хочет вынести это условие на уровень выше, где t и подсоединяется к другим таблицам, т.е. на where запроса, но в этом случае пропадает смысл левого соединения, потому он и не может вынести.
Указание в явном виде сначала соединения t и l по условию "t.LicNum = l.LicNum" дает право при подсоединении слева FinTreat в условии использовать ссылки на обе таблицы и на t и на l.
Проблема не в порядке следования таблиц во from, а в том, что к чему подсоединяется и как это указывается. Три таблицы можно пересечь множеством способов и получить иное множество различных результатов. From - это не мясорубка.

В Вашем случае есть два правильных варианта:



Если бы подключение таблицы ft требовало ссылок и на t и на l, то прошел бы только второй вариант.

P.S.: Остается один вопрос. В чем сакраментальный смысл левого подсоединения, если по этой таблице берется сумма и только сумма? Там оно совершенно не нужно.

amakhin
А если в таблице fintreat не окажется ни одной записи для сущности из MaxInsur, то разве при inner join мы не потеряем эту запись из этой таблицы?

Потеряем. А разве потеряные строки смогут что-то изменить в Sum(ft.Finance), если в их случае ft.Finance is null, и они и так пролетят мимо кассы?!!

amakhin,

Ну раз это нужно, значит надо с левым подсоединением. Только нужно экранировать Sum(isnull(ft.Finance,0))