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))

amakhiniLLer, экранировать или нет - это как раз зависит от обработки на клиенте, и смысл будет разные или отсутсвие записей или нулевые обороты.
Ну тогда не экранируйте. Обновите клиента и будет счастье.

P.S. left outer join делается не ко всем перечисленным до него таблицам через запятую, а к одной сущности. В качестве такой сущности может идти соединение других таблиц. Запятая не является соединением.
Поэтому конструкция
не является корректной. И дело не в оптимизаторе.
Если и читать, то только ANSI SQL, ASA тут ни причем.

White OwlВообще-то, эта конструкция вполне даже работающая. Она не чиста с точки зрения стандартов, но все сервера где я ее пробовал (включая ASE 7-11) прекрасно ее отрабатывают.
Хм. Если спичка лезет в замочную скважину, это еще не значит, что это ключ.
Если оптимизатор пропускает такую конструкцию, значит он ОДНОЗНАЧНО считает, что сначала перемножит две таблицы A и B, и только после этого приступает к рассмотрению возможностей подсоединения третьей, C. Не очень умный оптимизатор, так скажем. Откуда ему заранее известно, что так будет проще, а не сначала соединить B и C, и только потом перемножить с A?! Ему это не может быть известно, а значит множество потенциальных планов изначально искусственно ограничено, и внедрен именно такой подход к разбору синтаксиса.
"Работающая" еще не значит корректная. Примерно тоже самое, что написать в where условие "0/0=0/0", вроде ничего не меняет, однако некорректно.

White OwlВообще-то, он сначала сделает B&C, а потом добавит A.
Я наверно "не въехал". А как он сможет???? Если для соединения B и C ему нужно посчитать условие "C.a=A.b", а в нем упоминается еще не проявленная A... Возможно оптимизаторы пропускающее такое и не такие простые. Видимо есть какое-то объяснение для существования такой конструкции.

MasterZiv,

Наверно Вы хотели сказать, что форма записи не должна определять способ выполнения. Конечно, в теории это так и есть. Я говорил лишь про сервера, которые глотают такую фигню. И факт этого глотания говорит лишь об одном, что некорректность соединения B и C сервер может не заметить только в одном случае, когда он априори и не пытается проанализировать эту возможность. В противном случае он бы возвращал ошибку. А раз не возвращает, значит подход к анализу усеченный.
Я правильно Вас понимаю, что Вы допускаете возможность существования некоего гипотетического сервера, который бы с одной стороны молча принимал такую конструкцию, а с другой, при построении плана выполнения заценивал все возможные стоимости включая подход сначала B и C, а потом перемножение с A?! И, очевидно, натыкаясь на ошибку тупо отбрасывал этот план с неудавшейся стоимостью, а оставлял тот, который позволил бы выполнить запрос?

MasterZiv,

Может Вы тоже не заметили "прикола"?
Хорошо. Гипотетический сервер существует. Представим, что мы это он. Попытаемся заценить стоимость обработки запроса в случае, когда мы сначала хотим пересечь B и C, и только потом A. Чтобы посчитать общую стоимость, нужно посчитать стоимость частей. Какова будет стоимость "B left outer join C on C.a=A.b"? Вы можете прикинуть, при условии, что Вы вообще не знаете что такое A.b, т.к. отложили A на потом! Оценка невозможна, т.к. на соединение B и C нельзя наложить условие "C.a=A.b". Вот и ошибка синтаксиса.

Поэтому, либо слепой оптимизатор, либо ошибка синтаксиса.

MasterZiv
Здесь нет никакой ошибки синтаксиса. По семантике операции left outer join
A должно быть перед С. А вот при чём тут B, или как его JOIN записан --
не понятно.

Я кажется понял на что Вы намекаете. Т.е., следуя Вашим утверждениям, следующий запрос уже имеет ошибку синтаксиса, т.к. A упоминается не перед, а после C?!

Но, позвольте, разве от изменения порядка следования перечисляемых что-то меняется? Так скажем, должно ли меняться? Сдается мне, что по стандарту SQL такого быть не должно.