Query из 7 таблиц

[Morpheus]

Цитата:

Сообщение от Yugene

тогда уж лучше использовать while select - с ним такой проблемы нет

А на форме как будете отображать такой запрос?

[iggl2]

Цитата:

Сообщение от Morpheus

А почему "золотые партнеры" бездействуют? Неужели нельзя поставить эту ошибку в очередь на исправление?

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

как писал db:

"2/22/2005 9:01:00 AM PST -- Sergey Gerasimov
Добрый день, Роман,

Ваш запрос 'Ошибка парсера заросов при разборе сложных запросов' принят в обработку.

С уважением
Сенргей Герасимов.
...
ну а по срокам
"8124246 Ошибка парсера заросов при разборе сложных запрос - Обозначено как кандидат для 4.0;""

[Morpheus]

Для Oracle парсится без ошибки...

[gl00mie]

Цитата:

Сообщение от ice

тогда уж лучше через ODBC соединиться с тем же SQL Server, и сделать запрос через него

Ага, и RLS идет лесом...

[Волчара]

Цитата:

Сообщение от slava

Я в шоке
Стоит уже делать ставки в каком десятилетии исправят.

Да не стоит напрягаться - не такая это уж и серьезная ошибка.
Со стороны Microsoft разумно заявить четкое ограничение на количество таблиц в Query.

А вот писать такие запросы на 7 таблиц - есть большая ошибка.
Cornflower - вы моделировали этот запрос в SQL Query Analyzer? Если нет то попробуйте - может он вам все так подвесит, что и возиться не стоит?

[gl00mie]

Цитата:

Сообщение от Волчара

А вот писать такие запросы на 7 таблиц - есть большая ошибка. Cornflower - вы моделировали этот запрос в SQL Query Analyzer? Если нет то попробуйте - может он вам все так подвесит, что и возиться не стоит?

Неправда ваша, бывает нужно и большее число таблиц связать - в основном это, конечно, одна-две транзакционные таблицы и куча справочников. Простой пример: нужно построить отчет по нескольким компаниям с накладными по поставщикам в разрезе договоров, поставщики группируются по внешним кодам, в отчете отдельно выделяются суммы по накладным расходам, распределенным на строки номенклатуры, при этом отфильтровываются "внутренние" контрагенты, связанные через CommerceGateway с другими компаниями, т.е. если поставщик DAT связан с компанией DAT, то он в отчет попасть не должен. Для отчета берутся: VendInvoiceJour, VendInvoiceTrans, VendTable, ExtCodeValueTable, RContractTable, GatewayOrgRef, GatewayOrganization и MarkupTrans (это если использовать MarkupTrans.CustVendPosted_RU, иначе еще придется цеплять MarkupTable) - итого 8 таблиц. Первым делом строится запрос SQL и прогоняется в Query Analyzer, чтобы посмотреть, те ли вообще данные получатся на выходе и за какое время они получатся, а уже потом это все переводится в Query, и начинается мучительная борьба с ограничениями и бзиками парсера запросов

[Волчара]

Цитата:

Сообщение от gl00mie

...нужно построить отчет по нескольким компаниям с накладными по поставщикам в разрезе договоров, поставщики группируются по внешним кодам, в отчете отдельно выделяются суммы по накладным расходам, распределенным на строки номенклатуры, при этом отфильтровываются "внутренние" контрагенты, связанные через CommerceGateway с другими компаниями, т.е. если поставщик DAT связан с компанией DAT, то он в отчет попасть не должен. Для отчета берутся: VendInvoiceJour, VendInvoiceTrans, VendTable, ExtCodeValueTable, RContractTable, GatewayOrgRef, GatewayOrganization и MarkupTrans (это если использовать MarkupTrans.CustVendPosted_RU, иначе еще придется цеплять MarkupTable) - итого 8 таблиц. ...

Такой query со связями 1:n превратиться в SQL в несколько вложенных запросов. По этому с точки зрения загрузки сервера это менее актуально.

Кстати, возможно для такого Query - количество таблиц и не имеет столь жестких ограничений. Ни кто не проверял ?

Наконец если при настройке системы позаботиться об этом заранее, то можно сократить Query на 2-3 таблицы.

[Morpheus]

Цитата:

Сообщение от Волчара

Такой query со связями 1:n превратиться в SQL в несколько вложенных запросов. По этому с точки зрения загрузки сервера это менее актуально.

Наконец если при настройке системы позаботиться об этом заранее, то можно сократить Query на 2-3 таблицы.

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

[gl00mie]

Цитата:

Сообщение от Волчара

Кстати, возможно для такого Query - количество таблиц и не имеет столь жестких ограничений. Ни кто не проверял ?

Я проверял - половина таблиц не выбирается, пришлось возиться с подзапросами и кэшировать данные в Map'ах.

Цитата:

Наконец если при настройке системы позаботиться об этом заранее, то можно сократить Query на 2-3 таблицы.

Угу, обзывать всё и во всех компаниях одинаковыми кодами, поналепить в таблицы с проводками кучу дополнительных полей, дублирующих данные из справочников, вместе с кособокими неповоротливыми механизмами, обновляющими эти данные при изменении справочников, сюда не ходить, здесь не смотреть и вообще свести работу SQL-сервера к выборкам со сложностью на уровне dbf.

[Волчара]

Цитата:

Сообщение от gl00mie

Я проверял - половина таблиц не выбирается, пришлось возиться с подзапросами и кэшировать данные в Map'ах.

Ладно, убедили - пишите в Микрософт коллективную жалобу...