Как обойти The maximum number of tables in a query (260) ...

[Александр]

При использовании в действиях Party переменной типа объект с настроенными выражениями поиска если их более 10
наш MSSQL 2000 Sp4 выдает ошибку

Код: Выделить всё

The maximum number of tables in a query (260) was exceeded 

связанную с избыточным количеством таблиц участвующих в запросе отбора объектов
Понятно что это ограничение Microsoft? Но не понятно зачем Лоция формирует столь длинный запрос

Никто не посоветует как бы обойти данную проблему?
-может в переменной действия заменить запрос сформированный автоматически - на свой оптимизированный, поскольку запрос для данного действия всегда один (только значения разные)?
-или через свою хп делать запрос помещая результаты в окно выбора объекта?

ведь должен быть какой нибудь способ, кроме перехода на MSSQL 2005/Oracle/Sybase

[Anderyt]

что, это ограничение есть и в действии?????
у нас еще не было действий, где в поиске объектов есть около 10 атрибутов... но мало ли, может и такое нас скоро ждет..
я помню, есть такое ограничение при работе с вкладками типа Дочерние объекты, Входимость или Связанные объекты, там тоже нельзя сделать много колонок...
и меня с самого начала, когда узнал от Теххелпа про это ограничение, не дает покая такая мысль - почему в обычном отчете можно сделать дофига, извинияюсь, атрибутов, и все будет нормально, а на этих вкладках стоит сделать 10 - и все, приехали?? вот почему так????

а здесь, с объектами... хм... а что, ведется поиск сразу по всем 10-ти атрибутам??

[Александр]

нужно бы по 10 а так по 5х2 (к сожалению картинку приложить не могу наши админы закрыли mail.ru как сайт мешающий работе, а я туда все картинки и кидал)

Смотри, может ты подскажешь альтернативу
Есть диалог где я предлагаю на выбор (по флажку) ввести
-строку для поиска по описанию объекта
и/или
-строку для поиска в атрибуте 1 объекта
...
и/или
...
-строку для поиска в атрибуте 10 объекта

Соответственно пользователь отмечает нужные поля, вводит значения и начинает поиск
т.к. при отборе объекта я не могу анализировать сколько атрибутов поиска запрашивает пользователь (сколько галочек он поставил) приходится в условие поиска ставить ВСЕ (просто где флаг не отмечен - запрашивать '%')
так вот строка(диалог) настройки отбора объектов принимает вид

Код: Выделить всё

1  ( описание  =   mStr1  ) 1 И 
2 (( атрибут1  сущ          0 ИЛИ
0    атрибут1  *   mStr2  ) 1 ИЛИ
1  ( атрибут2  сущ          0 ИЛИ
0    атрибут2  *   mStr3  ) 1 ИЛИ
...
1  ( атрибут5  сущ          0 ИЛИ
0    атрибут5  *   mStr10 ))2 ИЛИ

т.е. проверка идет по 2 раза - есть ли атрибут? ИЛИ есть ли значение?

Хотелось бы конечно формировать условие отбора объекта в реальном времени - но это не реально

А так два выхода:
- предлагать поиск не более чем по 5 атрибутам одновременно
- создать 25 переменных типа объект перекрывающих все возможные комбинации запрашиваемых атрибутов

Но на самом деле все это неинтересно (то что Лоция рисует громадные запросы а Microsoft это дело посылает куда подальше) вот если бы знать точку входа (таблицу) окна отбора объектов и вставлять туда свои данные отобранные своим SQL тогда-бы всем было хорошо... может сделаем сами? ведь это всего навсего View's

[Anderyt]

не, влезать в стандартные процедуры или подсовывать к ним на вход что то свое - это не по мне..
минуточку.. а почему поиск нужно делать именно в виде поиска ОБЪЕКТА?
почему не сделать поиск в отчете?
у нас так сделан поиск чертежей, сначала юзер выбирает условия поиска, а потом они передаются на вход в отчет, в котором уже свой запрос.. и вид этого отчета можно настраивать, кстати.. работает не так уж и медленно.
и можно из отчета открыть любой заинтересовавший объект, если не понравится - закрыть его и открыть другой из этого же отчета.
но при этом все равно поиск делается по всем атрибутам, которые предусмотрены... и не хватает возможности динамически формировать запрос..
способ, который вчера предложил Юрий, я откровенно не понял и даже боюсь пробовать понимать..
но все равно, поиск объекта с помощью отчета у нас работает
и в отчете - обычный сиквел-запрос

[Александр]

так так.....
Вот за что мне нравится форум так это за взгляд на проблему с другой стороны.

Отчет для выбора -это конечно не привычно Но:
-свой SQL !!!!!!!!!!!
-возможность открыть несколько выбранных объектов !!!!!!!!!!!

нет слов - СПАСИБО!

PS и ведь знаешь - пользовался этим тысячу раз но смотрел на это только как на отчет...

[Anderyt]

-свой SQL !!!!!!!!!!!
-возможность открыть несколько выбранных объектов !!!!!!!!!!!

да, эти вещи мне тоже кажутся сильными сторонами такого подоха к поиску объектов

а кстати... вы разбирались, откуда в запросе, в котором всего 10 атрибутов для поиска и 4 колонки для возврата появляется 250 с лишним таблиц?? это что, на самом деле так??
но откуда??

даже если вспомнить, что на каждый атрибут нужно две таблицы (минимум), то откуда 255???

а.... кажется понял... это нужно сказать спасибо встроенной проверке прав, которая работает при обращении к видам.... эх....[/quote]

[Александр]

...кроме того Лоция кроссплатформена и автоматически формирует избыточные запросы чтобы они работали в любом случае на любой базе

это конечно сильно - но навязчиво...
если уж компания дала нам в руки инструмент разработки то весь предложенный ею сервис должен только помогать (и при необходимости иметь возможность отключения) но никак не мешать

это мое личное мнение

[Anderyt]

не, я вот с этим:

...кроме того Лоция кроссплатформена и автоматически формирует избыточные запросы чтобы они работали в любом случае на любой базе

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

ведь смотрите, каждое клиентское место знает, какая платформа.. и уже на этом этапе в логике программы можно подсовывать определенные запросы, характерные для НАШЕЙ платформы..
а вообще, нет, не совсем так
все запросы, насколько я понимаю, хранятся в БД в виде процедур. клиент просто вызывает определенную процедуру (набор процедур и их названия вообще могут быть одинаковыми для разных платформ), а сервер уже выполняет те инструкции, которые есть в этой конкретной процедуре для этой конкретной платформы..
ну это так, мысли вслух
но все таки, по-моему, избыточность запросов не связана с кроссплатформенностью

может быть, кто то сможет внести ясность в этот вопрос?
а, коллеги?

[Юрий]

Полностью согласен - избыточные запросы не из-за мультиплатформенности, а из-за лени разработчиков.
Согласитесь, гораздо проще написать запрос, который работает сразу на всех платформах, но этот запрос по определению не будет использовать оптимизацию для конкретной платформы. И будет работать медленно.
С другой стороны действительно логичнее для поддержки разных баз сделать встроенные процедуры в базе и из программы вызывать их, причем программе будет до фонаря, какой код в этих процедурах. А таким образом можно написать процедуры оптимизированные под конкретную платформу.
На практике - лоция формирует большую часть запросов в программе, естетсвенно головняк расписывать формирование запросов для каждой платформы - легко запутаться.
Отсюда избыточные запросы!

[Старик Крупский]

а кстати... вы разбирались, откуда в запросе, в котором всего 10 атрибутов для поиска и 4 колонки для возврата появляется 250 с лишним таблиц?? это что, на самом деле так??
но откуда??

Microsoft вроде считает каждое упоминание имени таблицы. Смотрите:
select attrib.id, attrib.description from attrib where attrib.id > 0

Угадайте сколько таблиц? Четыре!!!

[Александр]

Кстати, коллеги....
мы случайно наткнулись на схожую неприятность в случае с пользовательским отчетом (т.е. отчетом на своем SQL)

итак Лоция 4.20, Пользовательский отчет, Форма аргументов,
- если этих аргументов более 10 Лоция выдает ошибку
в начале темы также говорилось о 10 условиях поиска объекта - но там была своя ошибка

кроме того
Если в отчете (в SQL) использовать объединение таблиц (в where или в from (join on)) - Интерпритатор Лоции формирует неверный запрос к базе
Например делаем запрос из Query Analyzer, он выдает 254 строки
а тот же запрос из пользовательского отчета Лоции 47498 строк (отчет Лоции дублирует каждую запись *187 раз *(47498/187=254) )

может здесь собака порылась, и если Лоция решит эту проблему у нас вообще будет все летать???

[Anderyt]

такое чувство, что join интерпретировался не так...
а в запросе JOIN какой? простой? или хитрый какой то?
и можно ли добиться того, чтобы в QA тоже была ТА ЖЕ уйма строк - 47 498 ??
тогда можно будет примерно понять, ВО ЧТО именно Лоция интерпретировала запрос...

[Александр]

например так

Код: Выделить всё

SELECT rv.description as prod_Name, vv.value AS prod_Status
 FROM lsdbo.object_reference_view AS rv
             JOIN lsdbo.object_type_view AS tv ON rv.type_id=tv.id
             JOIN lsdbo.attrib_value_view AS av ON av.object_id=rv.id AND av.object_id=rv.id
             JOIN lsdbo.value_string_view AS vv ON vv.id = av.value_id
WHERE rv.type_id IN (100006459500000,100023044500000,100024516500000,-103)
             AND av.treelink_id = 0
             AND av.attrib_id = 100007986500005 

техподдержка в курсе, и уже неделю молчит....
Но если она решит эту проблему наша объектно ориентированная модель блестнет на все 100. Не надо будет городить цепочки связанных отчетов и терять время на передачу аргументов - все будет решаться в одном запросе путем объединения нескольких таблиц

[Anderyt]

мне кажется, вот такой запрос:

Код: Выделить всё

SELECT rv.description as prod_Name, 
(select vv.value
from 
lsdbo.attrib_value_view AS av
,lsdbo.value_string_view AS vv
where
av.object_id=rv.id
and
vv.id = av.value_id
and
av.attrib_id = 100007986500005
and
av.treelink_id = 0
) as prod_Status 
from
lsdbo.object_reference_view AS rv
,lsdbo.object_type_view AS tv 
where
rv.type_id=tv.id
and
rv.type_id IN (100006459500000,100023044500000,100024516500000,-103)

дает то же самое..
но без JOIN
что, если использовать такую конструкцию?
и в чем смысл av.treelink_id = 0 ?? это условие обязательно?

[Александр]

ты конечно хитер
но дело не в этом (да это тоже самое) но что ты скажешь на такое объединение
Найти нужные объекты (продукты)(1й Select) взять нужные атрибуты, дополнить информацией о клиентах покупающих эти продукты (2q Select) и информацией о контактных лицах непосредственно сделавших заказ (3й Select)

Код: Выделить всё

Select *
  From 
--первый запрос (основной)
/************************************************************************************************/
 (SELECT lsdbo.object_reference_view.description as prod_Name ,
             (SELECT vv.value 
                FROM lsdbo.attrib_value_view av,
                     lsdbo.value_string_view vv 
               WHERE av.value_id = vv.id 
                     AND av.object_id = lsdbo.object_reference_view.id 
                     AND av.treelink_id = 0 
                     AND av.attrib_id = 100007986500005) as prod_Status,
              (SELECT vv.value 
                FROM lsdbo.attrib_value_view av,
                     lsdbo.value_numeric_view vv 
               WHERE av.value_id = vv.id 
                     AND av.object_id = lsdbo.object_reference_view.id 
                     AND av.treelink_id = 0 
                     AND av.attrib_id = 100004060300000) as id_Client,
             (SELECT vv.value 
                FROM lsdbo.attrib_value_view av,
                     lsdbo.value_numeric_view vv 
               WHERE av.value_id = vv.id 
                     AND av.object_id = lsdbo.object_reference_view.id 
                     AND av.treelink_id = 0 
                     AND av.attrib_id = 100004081100000) as id_Contact
  FROM   lsdbo.object_reference_view,
         lsdbo.object_type_view    
  WHERE (lsdbo.object_reference_view.type_id = lsdbo.object_type_view.id)
         and (lsdbo.object_reference_view.type_id 
                 in(100006459500000,100023044500000,100024516500000,-103)) 
         and (lsdbo.object_reference_view.id 
                 in (Select av.object_id
                       From lsdbo.attrib_value_view av,
                            lsdbo.value_numeric_view vv
                      Where av.value_id = vv.id 
                            and av.attrib_id = 100004060500000 
                            and vv.attrib_id = 100004060500000 
                            AND vv.Value > 0))   )as Product_Table,

--дополнительный второй запрос на основе первого
/************************************************************************************************/
 (SELECT lsdbo.object_reference_view.description as client_Name,
         lsdbo.object_reference_view.id Client_Id,  
             (SELECT vv.value 
              FROM lsdbo.attrib_value_view av,
                   lsdbo.value_string_view vv 
             WHERE av.value_id = vv.id 
                   AND av.object_id = lsdbo.object_reference_view.id 
                   AND av.treelink_id = 0 
                   AND av.attrib_id = 100000016000000) as Client_Status
  FROM   lsdbo.object_reference_view,
         lsdbo.object_type_view    
  WHERE (lsdbo.object_reference_view.type_id = lsdbo.object_type_view.id)
         and (lsdbo.object_reference_view.id 
             in (SELECT 
                    (SELECT vv.value 
                       FROM lsdbo.attrib_value_view av,
                            lsdbo.value_numeric_view vv 
                      WHERE av.value_id = vv.id 
                            AND av.object_id = lsdbo.object_reference_view.id 
                            AND av.treelink_id = 0 
                            AND av.attrib_id = 100004060300000) as id_Client
                   FROM lsdbo.object_reference_view,
                        lsdbo.object_type_view    
                  WHERE (lsdbo.object_reference_view.type_id = lsdbo.object_type_view.id)
                         and (lsdbo.object_reference_view.type_id 
                            in(100006459500000,100023044500000,100024516500000,-103)) 
                         and (lsdbo.object_reference_view.id 
                            in (Select av.object_id
                                  From lsdbo.attrib_value_view av,
                                       lsdbo.value_numeric_view vv
                                 Where av.value_id = vv.id 
                                       and av.attrib_id = 100004060500000 
                                       and vv.attrib_id = 100004060500000 
                                       AND vv.Value > 0)) )))as Client_Table,

--дополнительный третий запрос на основе первого
/************************************************************************************************/
  (SELECT lsdbo.object_reference_view.description as Contact_Name,
       lsdbo.object_reference_view.id as Contact_Id,  
      (SELECT vv.value 
         FROM lsdbo.attrib_value_view av,
              lsdbo.value_string_view vv 
        WHERE av.value_id = vv.id 
              AND av.object_id = lsdbo.object_reference_view.id 
              AND av.treelink_id = 0 
              AND av.attrib_id = 3000000000062) as Contact_email
   FROM   lsdbo.object_reference_view,
          lsdbo.object_type_view    
  WHERE  (lsdbo.object_reference_view.type_id = lsdbo.object_type_view.id)
          and (lsdbo.object_reference_view.id 
             in (SELECT 
                    (SELECT vv.value 
                       FROM lsdbo.attrib_value_view av,
                            lsdbo.value_numeric_view vv 
                      WHERE av.value_id = vv.id 
                            AND av.object_id = lsdbo.object_reference_view.id 
                            AND av.treelink_id = 0 
                            AND av.attrib_id = 100004081100000) as id_Contact
                   FROM lsdbo.object_reference_view,
                        lsdbo.object_type_view    
                  WHERE (lsdbo.object_reference_view.type_id = lsdbo.object_type_view.id)
                         and (lsdbo.object_reference_view.type_id 
                            in(100006459500000,100023044500000,100024516500000,-103)) 
                         and (lsdbo.object_reference_view.id 
                            in (Select av.object_id
                                  From lsdbo.attrib_value_view av,
                                       lsdbo.value_numeric_view vv
                                 Where av.value_id = vv.id 
                                       and av.attrib_id = 100004060500000 
                                       and vv.attrib_id = 100004060500000 
                                       AND vv.Value > 0)) ))) as Contact_Table
/************************************************************************************************/

--объединение по id
Where (Product_Table.id_Client=Client_Table.Client_Id)
       and
      (Product_Table.id_Contact=Contact_Table.Contact_Id)

код стандартный но результаты в QA и Лоции разные
Объединение интерпретируется Лоцией неверно (как в стиле SQL так и в стиле Microsoft)