Разные запросы в 2-х и 3-х уровневой конфигурациях. Что делать?!

[Anais]

Многоуважаемая публика. Столкнулась со странной ситуацией: при формировании отчета в 2-х и в 3-х уровневых конфигурациях Axapta отправляет на SQL-сервер разные (!) запросы.
В 2-х уровневой версии запрос уходит на сервер вот в таком виде:

SELECT A.VOUCHER,A.TRANSDATE,A.BGR_INVENTTRANSID,SUM(B.AMOUNTMST),SUM(B.AMOUNTCUR),B.ACCOUNTNUM,B.CREDITING,B.VOUCHER,B.TRANSDATE,B.BGR_INVENTTRANSID
FROM LEDGERTRANS A,LEDGERTRANS B
WHERE ((A.DATAAREAID='bgr')
AND ((((((((A.TRANSDATE>={ts '2004-06-01 00:00:00.000'}) AND (A.TRANSDATE<={ts '2004-06-30 00:00:00.000'}))
AND NOT ((A.BONDBATCH_RU=' '))) AND NOT ((A.BONDBATCHTRANS_RU=0)))
AND ((A.PERIODCODE>=1) AND (A.PERIODCODE<=2)))
AND NOT ((A.POSTING=19)))
AND (A.VOUCHER=' ВП-00000060'))
AND ((((((((((A.TRANSTYPE=0) OR (A.TRANSTYPE=3)) OR (A.TRANSTYPE=14)) OR (A.TRANSTYPE=16)) OR (A.TRANSTYPE=19)) OR (A.TRANSTYPE=20))
OR (A.TRANSTYPE=82)) OR (A.TRANSTYPE=80)) OR (A.TRANSTYPE=9)) OR (A.TRANSTYPE=99))))
AND ((B.DATAAREAID='bgr')
AND (((B.RECID<>A.RECID) AND (A.BONDBATCH_RU=B.BONDBATCH_RU)) AND (A.BONDBATCHTRANS_RU=B.BONDBATCHTRANS_RU)))
GROUP BY A.VOUCHER,A.TRANSDATE,A.BGR_INVENTTRANSID,B.ACCOUNTNUM,B.CREDITING,B.VOUCHER,B.TRANSDATE,B.BGR_INVENTTRANSID
ORDER BY A.VOUCHER,A.TRANSDATE,A.BGR_INVENTTRANSID,B.ACCOUNTNUM,B.CREDITING,B.VOUCHER,B.TRANSDATE,B.BGR_INVENTTRANSID
OPTION(FAST 19)

А в 3-уровневой, вот в таком:

SELECT A.VOUCHER,A.TRANSDATE,A.BGR_INVENTTRANSID,SUM(B.AMOUNTMST),SUM(B.AMOUNTCUR),B.ACCOUNTNUM,B.CREDITING,B.VOUCHER,B.TRANSDATE,B.BGR_INVENTTRANSID
FROM LEDGERTRANS A,LEDGERTRANS B
WHERE ((A.DATAAREAID='bgr')
AND ((((((((A.TRANSDATE>={ts '2004-06-01 00:00:00.000'}) AND (A.TRANSDATE<={ts '2004-06-30 00:00:00.000'}))
AND NOT ((A.BONDBATCH_RU=' '))) AND NOT ((A.BONDBATCHTRANS_RU=0)))
AND ((A.PERIODCODE>=1) AND (A.PERIODCODE<=2)))
AND NOT ((A.POSTING=19)))
AND (A.VOUCHER=' ВП-00000060'))
AND (((((((((A.TRANSTYPE=3) OR (A.TRANSTYPE=14)) OR (A.TRANSTYPE=16)) OR (A.TRANSTYPE=19))
OR (A.TRANSTYPE=20)) OR (A.TRANSTYPE=82)) OR (A.TRANSTYPE=80)) OR (A.TRANSTYPE=9)) OR (A.TRANSTYPE=99))))
AND ((B.DATAAREAID='bgr')
AND (((B.RECID<>A.RECID) AND (A.BONDBATCH_RU=B.BONDBATCH_RU))
AND (A.BONDBATCHTRANS_RU=B.BONDBATCHTRANS_RU)))
GROUP BY A.VOUCHER,A.TRANSDATE,A.BGR_INVENTTRANSID,B.ACCOUNTNUM,B.CREDITING,B.VOUCHER,B.TRANSDATE,B.BGR_INVENTTRANSID
ORDER BY A.VOUCHER,A.TRANSDATE,A.BGR_INVENTTRANSID,B.ACCOUNTNUM,B.CREDITING,B.VOUCHER,B.TRANSDATE,B.BGR_INVENTTRANSID OPTION(FAST 19)

Разница отмечена жиным шрифтом: в 2-х уровневой конфигурации добавляется лишний фильтр, который совсем даже не лишний..... Причем, если идти по циклу в дебагере, то фильтр добавляется в обеих конфигурациях. А на SQL-сервер в итоге уходят разные запросы!

УЖАС! Кто-нибудь сталкивался с таким? Знает как бороться?!

[Hezl]

Попробуйте почистить кэш в 3-звенке.

[levsha]

сталкивался с подобной проблемой, правда безотносительно отчетов.
Строился Query добавлялись в него фильтры, а затем при вызове QueryRun.next()
отправлялись разные фильтры взависимости от конфигурации(в двухуровневой фильтр целиком, в трехуровневой с недостающим условием). Моя проблема вылечилась, когда я стал определять объекты Query и QueryRun на одной стороне (либо оба на сервере, либо оба на клиенте). Когда проблему обнаружил, query у меня определялся с одной стороны, а вызов new QueryRun(query) на другой стороне. Может это как-то сможет Вам помочь.

[Anais]

Да какой там кэш Я ее тут только-только запустила, первый раз за месяц, наверное, - специально, чтобы разобраться, почему отчет не работает. А тут -такое!
Спасибо за версию - но дело не в этом.

[Anais]

Цитата:

Изначально опубликовано levsha
Моя проблема вылечилась, когда я стал определять объекты Query и QueryRun на одной стороне (либо оба на сервере, либо оба на клиенте). Когда проблему обнаружил, query у меня определялся с одной стороны, а вызов new QueryRun(query) на другой стороне. Может это как-то сможет Вам помочь.

ТОЧНО!
Query действительно определялся на стороне клиента, а QueryRun - в серверном классе, формирующем данные для отчета.
Сейчас проблема успешно излечена, спасибо огромное!

Добавлю еще, что попытка вылечиться "простым" способом, сделав в серверном классе при инициализации параметров:
query = new Query(_query);
к успеху НЕ привела.

Действенных решений 2:
1. Объявить класс, в котором делается самое первое query = new Query() серверным.
2. Перенести ту часть формирования query, в которой добавляются Range'и по "сбоящему" полю (в моем случае - по TRANSTYPE) в серверный класс, в котором делается QueryRun.

[George Nordic]

Либо не использовать смешанные конфигурации (Очень рекомендую)

P.S. Anais, levsha! Спасибо за описание интересного бага и способа лечения.

С Уважением,
Георгий.

[levsha]

Цитата:

Изначально опубликовано Anais

Перенести ту часть формирования query, в которой добавляются Range'и по "сбоящему" полю (в моем случае - по TRANSTYPE) в серверный класс, в котором делается QueryRun.

не очень хорошее предложение, потому как, без трассировки запросов едва ли удастся предсказать с каким Range произойдет сбой.

Плюс к этому в продолжении темы:
плохо в случае переноса QueryRun с клиента на сервер становится не только фильтрам... Сейчас наблюдал такую картину:
объекты Query и QueryRun формировались оба на клиенте, а вот вызов QueryRun.next() происходил уже на сервере. Фильтры и на толстом и на тонком клиентах формировались одинаковые (трассировка запросов давала идентичные результаты), но при этом на толстом клиенте процесс отрабатывал успешно, на тонком клиенте происходило зацикливание именно в выполнении процедур на аосе (никаких запросов дополнительно к серверу БД не формировалось, но между объектами на сервере происходила передача ссылки на этот объект QueryRun). Пришлось все параметры, необходимые для формирования query, дублировать на сервере...

[Rokhay]

Цитата:

Изначально опубликовано George Nordic
Либо не использовать смешанные конфигурации (Очень рекомендую)

Георгий.

а как же тогда вести разработку без возможности отладки дебагером серверных методов ?

[George Nordic]

На АОСе надо галку поставить - и все у Вас будет дебажиться и на сервере. Почитайте доку, а лучше - методом научного тыка - там её несложно найти.

С Уважением,
Георгий

[levsha]

Цитата:

Изначально опубликовано George Nordic
На АОСе надо галку поставить - и все у Вас будет дебажиться и на сервере.

есть и те, кто до сих пор мучается на 2.5...

[savel]

Цитата:

Изначально опубликовано George Nordic
На АОСе надо галку поставить - и все у Вас будет дебажиться и на сервере. Почитайте доку, а лучше - методом научного тыка - там её несложно найти.

С Уважением,
Георгий

Галка появилась в 3.0, Вы не забывайте про 2.5. У нас все пользователи входят тонким. А в интересах разработки приходится пользоваться и толстым клиентом.

[George Nordic]

Да, точно. в 2,5 её не было
Сорри, если кого ввел в заблуждение.

С Уважением,
Георгий.

[levsha]

Цитата:

Изначально опубликовано Anais

Многоуважаемая публика. Столкнулась со странной ситуацией: при формировании отчета в 2-х и в 3-х уровневых конфигурациях Axapta отправляет на SQL-сервер разные (!) запросы.

Axapta немножко расслабляет программиста и ему редко приходится задумываться над тем как он управляет на сервере "ссылкой" на объект, сформированный на клиенте, и наоборот. Вот такие "баги" только и одергивают иногда. А между тем, по всей видимости это вовсе и не баг. Во всяком случае достаточно воспользоваться рекоммендациями MBS и передавать между клиентом и сервером не ссылку на объект, а контейнер, формируемый методом pack. Затем на противоположной стороне надо воспользоваться в данном случае new(container). В противном случае некорректное поведение получаем не только в случае Query и QueryRun, подобную ерунду получаем и при инициализации на разных сторонах List и ListIterator, Map и MapIterator и т.д.