Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Не видно столбцов из соседнего набора
|
|||
|---|---|---|---|
|
#18+
Есть запрос с несколькими уровнями подзапросов. В общем выглядит деревообразно: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Итого в глубину 5 уровней. При очередном join-е для оптимизации нужно в where подставить значение из уровня выше. Если ставить его в условие on, то подзапрос сначала формирует выборку по всем данным таблицы и только потом отбирает нужные строки для сцепки по join. Проблема заключается в том, что при переносе условия в where и использования в нём значений из предыдущего уровня DB2 перестает их узнавать. Даже переменные хранимой процедуры (запрос выполняется в процедуре) становятся неизвестными. Код: plaintext Может есть ограничение на количество уровней? --------------------------------------------------------- IS NULL OR NOT IS NULL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 11:31 |
|
||
|
Не видно столбцов из соседнего набора
|
|||
|---|---|---|---|
|
#18+
BuryCommonerХотя, вроде, на более простых запросах всё отрабатывало нормально. В чем может быть дело? Может есть ограничение на количество уровней?Покажите более простой работающий запрос. Дело в том, что вы не можете использовать в подзапросе поля внешних таблиц (а только параметры или переменные процедуры или функции, в которой запрос написан), если только вы перед подзапросом не указываете слово table: Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 22:04 |
|
||
|
Не видно столбцов из соседнего набора
|
|||
|---|---|---|---|
|
#18+
Спасибо, проглючил, был напуган :) Действительно, так делать нельзя. Но проблема была. Потому что в where подзапроса я так же пытался использовать переменную хранимой процедуры. Причем в подзапросах выше она нормально находилась, а именно в данном подзапросе происходила ошибка SQL0204N Имя не было определено. Проблему пока решил изменением структуры хранения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2010, 07:04 |
|
||
|
Не видно столбцов из соседнего набора
|
|||
|---|---|---|---|
|
#18+
BuryCommonerНо проблема была. Потому что в where подзапроса я так же пытался использовать переменную хранимой процедуры. Причем в подзапросах выше она нормально находилась, а именно в данном подзапросе происходила ошибка SQL0204N Имя не было определено. Проблему пока решил изменением структуры хранения.Очень странно. Вот вам тестовая процедура, она генерирует вложенность любого уровня, заданного первым параметром. Текст выполняемого запроса выводится в 3-ем параметре. У меня до уровня 100 работает, т.е. параметр процедуры на этом уровне распознаётся. Если будете проверять, не задавайте уровень слишком большим - инстанс упасть может по переполнению стека. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2010, 12:47 |
|
||
|
Не видно столбцов из соседнего набора
|
|||
|---|---|---|---|
|
#18+
Прошу прощения за поздний ответ. Сам ошибочный запрос был утерян при оптимизации и повторить его не получилось. Проблема, скорее всего, была не в глубине вложенности. Запрос выполнялся в теле хранимой процедуры и занимал 5 экранов текста. Вероятно было превышено какое-то ограничение компилятора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2011, 12:30 |
|
||
|
|

start [/forum/moderation_log.php?user_name=_%D0%A1%D0%B5%D1%80%D0%B3%D0%B5%D0%B9__]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
38ms |
get topic data: |
8ms |
get first new msg: |
6ms |
get forum data: |
2ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 755ms |
| total: | 891ms |

| 0 / 0 |
