ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
19 сообщений из 44, страница 2 из 2
  2  все
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34444078
Jannny
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jannny
Участник
Timm Andrew MaxПри выполнении DDL оператора (CREATE OR REPLACE) парсинг, безусловно, происходит.
Но следующий пример показывает, что даже парсинг анонимного блока не вызывает ошибок, в то время как парсинг отдельного SQL-запроса приводит к ORA-00937:
...
Не понимаю, в чем может быть разница при парсинге анонимного/хранимого PL-блоков? Для чего этот пример? :)Потому что в приведенном примере продемонстрирован явный парсинг
...
Рейтинг: 0 / 0
06.04.2007, 16:20
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34444127
Andrew Max
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrew Max
Участник
Timm Andrew MaxПри выполнении DDL оператора (CREATE OR REPLACE) парсинг, безусловно, происходит.
Но следующий пример показывает, что даже парсинг анонимного блока не вызывает ошибок, в то время как парсинг отдельного SQL-запроса приводит к ORA-00937:
...
Для чего этот пример? :)
Ммм... пока думал, как ответить - за меня ответила Jannny. Спасибо.
Пример - ни для чего иного, кроме как в качестве ответа на мнение, высказанное здесь:

andrey_anonymous... мне представляется, что при компиляции PL/SQL кода парсинга SQL-запросов не происходит.
Пример с DBMS_SQL просто показал, что парсинг происходит-таки. Еще его, разумеется, можно увидеть "явно", через V$MYSTAT:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
SQL> select n.name, s.value
   2     from v$statname n,
   3          v$mystat s
   4    where n.name like 'parse count%'
   5      and n.statistic# = s.statistic#;

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
parse count (total)                                                      130 
parse count (hard)                                                        21 
parse count (failures)                                                     4 

SQL> /

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
parse count (total)                                                      132 
parse count (hard)                                                        21 
parse count (failures)                                                     4 

SQL> CREATE OR REPLACE PROCEDURE mytest AS
   2   BEGIN
   3      FOR rec IN (SELECT dummy, COUNT(*) FROM dual)
   4     LOOP
   5       NULL;
   6     END LOOP;
   7   END;
   8   /

Процедура создана.

SQL> select n.name, s.value
   2     from v$statname n,
   3          v$mystat s
   4    where n.name like 'parse count%'
   5      and n.statistic# = s.statistic#;

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
parse count (total)                                                      190 
parse count (hard)                                                        22 
parse count (failures)                                                     4

Но ошибки данный парсинг по каким-то причинам не вызывает. По поводу природы этих причин у меня пока гипотез нет.
...
Рейтинг: 0 / 0
06.04.2007, 16:32
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34444137
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Elic
Участник
TimmНе понимаю, в чем может быть разница при парсинге анонимного/хранимого PL-блоков? Для чего этот пример? :)Для того, чтобы показать, что парсер чисто-SQL-я и парсер SQL-я-внутри-PL/SQL-я - это всё ещё разные движки.
...
Рейтинг: 0 / 0
06.04.2007, 16:33
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34444194
Фотография Timm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Timm
Участник
Ага, понятно, спасибо.
...
Рейтинг: 0 / 0
06.04.2007, 16:46
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34444241
Andrew Max
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrew Max
Участник
Вячеслав Любомудров Jannny TiGНу тогда вспомним такую фичу как процедуры с правами вызывающего - что реально будет вызываться станет известно только на момент выполнения.Только в данном случае это совсем ни при чем...
Именно причем
Увы, ни функции, ни AUTHID здесь ни при чем.
В следующем примере уж точно нет ничего, что можно было бы посчитать функцией либо списать на механизм AUTHID:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
SQL> CREATE OR REPLACE PROCEDURE mytest AS
   2   BEGIN
   3      FOR rec IN (SELECT * FROM SYS.DUAL D GROUP BY NULL)
   4     LOOP
   5       NULL;
   6     END LOOP;
   7   END;
   8   /

Процедура создана.

SQL> exec mytest
BEGIN mytest; END;

*
ошибка в строке  1 :
ORA- 00979 : выражение не является выражением GROUP BY
ORA- 06512 : на  "MAX.MYTEST", line  3 
ORA- 06512 : на  line  1

Мое ИМХО: причина - в "недоделанности" парсера.
...
Рейтинг: 0 / 0
06.04.2007, 16:59
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34444276
andreymx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andreymx
Участник
Andrew MaxУвы, ни функции, ни AUTHID здесь ни при чем.
В следующем примере уж точно нет ничего, что можно было бы посчитать функцией либо списать на механизм AUTHID:
Код: plaintext
 FOR rec IN (SELECT * FROM SYS.DUAL D GROUP BY NULL)
Уважаю!
...
Рейтинг: 0 / 0
06.04.2007, 17:05
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34444327
Andrew Max
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrew Max
Участник
andreymx Andrew MaxУвы, ни функции, ни AUTHID здесь ни при чем.
В следующем примере уж точно нет ничего, что можно было бы посчитать функцией либо списать на механизм AUTHID:
Код: plaintext
 FOR rec IN (SELECT * FROM SYS.DUAL D GROUP BY NULL)
Уважаю!
Хм. Польщен. Засмущался.
Спасибо, тезка.

ЗЫ: Алиас "D" можно из примера выбросить, он, разумеется, ни на что не влияет.
...
Рейтинг: 0 / 0
06.04.2007, 17:16
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34444594
Фотография orawish
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
orawish
Участник
Andrew Max..
Мое ИМХО: причина - в "недоделанности" парсера.
+1
А банальная причина может быть в лени разбираться не есть ли это нечто
синтаксически корректное, например, при наличии окна:
Код: plaintext
select dummy,count(*) over() from dual
...
Рейтинг: 0 / 0
06.04.2007, 18:47
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34444899
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
Andrew MaxПри выполнении DDL оператора (CREATE OR REPLACE) парсинг, безусловно, происходит.
Тезка, парсинг ЧЕГО?
А происходит парсинг DDL-предложения "create or replace..."
При этом никакого парсинга проблемного sql-предложения "select from..." НЕ ПРОИСХОДИТ, в чем можно элементарно убедиться по трассе 10046.
Все, что делается - проверка синтаксиса, семантика же предожения select на этом этапе не проверяется.
Ладно молодые и горячие, но Вы-то... Иеххх, куда катится мир :)
...
Рейтинг: 0 / 0
07.04.2007, 01:17
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34444937
Владимир Бегун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Бегун
Участник
andreymx...

#2765516

P.S.: В мире много сказок, в мире много сказок, грустных и смешных... ;)
...
Рейтинг: 0 / 0
07.04.2007, 04:12
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34444943
Andrew Max
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrew Max
Участник
andrey_anonymous...
Процитирую один важный момент еще раз:
andrey_anonymous... мне представляется, что при компиляции PL/SQL кода парсинга SQL-запросов не происходит.
Да, признаю, я несколько поспешил с критикой, упустив из виду то, что акцент был сделан на словах "SQL-запросов".

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

andrey_anonymousПри этом никакого парсинга проблемного sql-предложения "select from..." НЕ ПРОИСХОДИТ, в чем можно элементарно убедиться по трассе 10046.
Вот здесь, на мой взгляд, нужно определиться с терминами.

Разумеется, в трассе 10046 в нашем случае не будет упоминаний об отдельных запросах в нашем PL/SQL-блоке, который подвергается парсингу. Конечно, не увидим мы никаких следов и в V$SQL, V$SQL_PLAN. Все это вполне логично и понятно: никаких SQL-курсоров на данном этапе мы не открываем и никаких планов выполнения не строим.

Но можем ли мы на основании этих факторов судить о том, что "никакого парсинга проблемного sql-предложения не происходит"?

Полагаю, что все-таки не можем.
Да, вышеперечисленные факторы дают нам основания полагать, что в нашей ситуации запросы не парсятся SQL-машиной. Но они, разумеется, обрабатываются PL/SQL-парсером, который, в силу особенностей своей реализации, иногда вот так вот чудит.

Разумеется, мы должны помнить о том, что парсинг - это не только построение планов. Строго говоря, планами вообще занимается не парсер, а query optimizer. А парсинг - это прежде всего синтаксическая и семантическая проверки , без которых статический SQL в PL/SQL - просто немыслим.

andrey_anonymousВсе, что делается - проверка синтаксиса, семантика же предложения select на этом этапе не проверяется.
Здесь категорически не согласен. Проверка семантики обязана выполняться ( и выполняется ).

К примеру, следующий запрос корректен синтаксически, но неверен семантически:

Код: plaintext
SELECT BLABLABLA FROM SYS.DUAL;

Семантические проверки - это проверки того, что указанные в запросе объекты существуют и пользователь имеет все необходимые привилегии. Столбец "BLABLABLA" отсутствует в таблице SYS.DUAL, поэтому семантическая проверка окончится неуспешно, хотя с синтаксической точки зрения звпрос корректен.

Разумеется, PL/SQL такой семантически некорректный запрос не пропустит:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
SQL> CREATE OR REPLACE PROCEDURE TESTA IS
   2   BEGIN
   3     FOR REC IN
   4       (SELECT BLABLABLA FROM SYS.DUAL)
   5     LOOP
   6       NULL;
   7     END LOOP;
   8   END;
   9   /

Warning: Procedure created with compilation errors.

SQL> show errors
Errors for PROCEDURE TESTA:

LINE/COL ERROR
-------- ----------------------------------------------------
 4 / 5       PL/SQL: SQL Statement ignored
 4 / 12      PL/SQL: ORA- 00904 : "BLABLABLA": invalid identifier
SQL>

А вот такой звпрос будет некорректным даже синтаксически:

Код: plaintext
SELECT * SYS.DUAL;

Например, вот здесь , в начале статьи все это обстоятельно описывается.

Так что - нет, пока что Вы не убедили меня в том, что при парсинге PL/SQL-блоков "никакого парсинга проблемных sql-предложений" не происходит. Происходит . Просто выполняется он, по-видимому, PL/SQL-парсером, что иногда приводит к таким вот казусам.

andrey_anonymousЛадно молодые и горячие, но Вы-то...
Я заинтригован.
Вы разве обладаете информацией относительно моего возраста?
:)
...
Рейтинг: 0 / 0
07.04.2007, 04:30
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34445072
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
Andrew MaxНо можем ли мы на основании этих факторов судить о том, что "никакого парсинга проблемного sql-предложения не происходит"?
Пришла моя очередь уточнить что конкретно я имел ввиду :)
А имел я ввиду тот факт, что в обсуждаемом случае парсинг не производится SQL-машиной, потому и ссылался на 10046.

Да, безусловно, парсинг - составная часть процесса компиляции PL/SQL кода. Но парсер PL/SQL машины - это совсем другой парсер, он разбирает PL/SQL.
Да, семантическая проверка - часть парсинга. Но семантика PL/SQL и семантика SQL - все-таки заметно отличаются. PL/SQL - императивен, SQL - декларативный язык. Поэтому парсер PL/SQL, несмотря на ряд выполняемых проверок, не может заменить собой парсер SQL.
...
Рейтинг: 0 / 0
07.04.2007, 12:29
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34445084
Рико
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Рико
Гость
andrey_anonymous
Да, безусловно, парсинг - составная часть процесса компиляции PL/SQL кода. Но парсер PL/SQL машины - это совсем другой парсер, он разбирает PL/SQL.
Да, семантическая проверка - часть парсинга. Но семантика PL/SQL и семантика SQL - все-таки заметно отличаются. PL/SQL - императивен, SQL - декларативный язык. Поэтому парсер PL/SQL, несмотря на ряд выполняемых проверок, не может заменить собой парсер SQL.
Отработка dbms_output в процедуре перед вызовом ошибки говорит, видимо, в пользу этих слов...
...
Рейтинг: 0 / 0
07.04.2007, 13:01
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34445114
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
РикоОтработка dbms_output в процедуре перед вызовом ошибки говорит, видимо, в пользу этих слов...
Не поясните свою мысль?
...
Рейтинг: 0 / 0
07.04.2007, 13:50
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34446200
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
С этим оператором что-то вообще не все понятно
Например, он не попадает в трассу -- ни разбор, ни ошибка. Возможно, надо выполнять трассировку с другим уровнем, но все равно это как-то аномально.
Еще мне интересно, почему в трассе нет ошибок выполнения?
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
tst> alter session set sql_trace=true;

Session altered.

tst> select Dummy, count(*) from dual;
select Dummy, count(*) from dual
       *
ERROR at line  1 :
ORA- 00937 : not a single-group group function


tst> select dm from dual;
select dm from dual
       *
ERROR at line  1 :
ORA- 00904 : "DM": invalid identifier


tst> select * from dual where dummy=
   2   (select  1  from dual union all select  2  from dual);
select * from dual where dummy=
                         *
ERROR at line  1 :
ORA- 01722 : invalid number


tst> select * from dual where dummy=
   2   (select '1' from dual union all select '2' from dual);
(select '1' from dual union all select '2' from dual)
 *
ERROR at line  2 :
ORA- 01427 : single-row subquery returns more than one row


tst> alter session set sql_trace=false;

Session altered.

tst> connect u1/u1@tst
Connected.
tst>
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
*** 2007-04-09 10:52:08.169
*** SESSION ID:(10.5864) 2007-04-09 10:52:08.169
APPNAME mod='SQL*Plus' mh=3669949024 act='' ah=4029777240
=====================
PARSING IN CURSOR #1 len=32 dep=0 uid=24 oct=42 lid=24 tim=2863421259068 hv=3943786303 ad='2f09e5dc'
alter session set sql_trace=true
END OF STMT
EXEC #1:c=0,e=266,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=2863421258761
*** 2007-04-09 10:52:20.374
=====================
PARSING IN CURSOR #2 len=198 dep=1 uid=0 oct=3 lid=0 tim=2863433178620 hv=2703824309 ad='2ff65780'
select obj#,type#,ctime,mtime,stime,status,dataobj#,flags,oid$, spare1, spare2 from obj$ where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null and linkname is null and subname is null
END OF STMT
PARSE #2:c=0,e=159,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2863433178603
EXEC #2:c=0,e=185,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2863433179400
FETCH #2:c=0,e=114,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=2863433179606
=====================
PARSING IN CURSOR #2 len=198 dep=1 uid=0 oct=3 lid=0 tim=2863440951894 hv=2703824309 ad='2ff65780'
select obj#,type#,ctime,mtime,stime,status,dataobj#,flags,oid$, spare1, spare2 from obj$ where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null and linkname is null and subname is null
END OF STMT
PARSE #2:c=0,e=149,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2863440951877
EXEC #2:c=0,e=136,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2863440952544
FETCH #2:c=0,e=65,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=2863440952782
EXEC #2:c=0,e=82,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2863440953282
FETCH #2:c=0,e=43,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=2863440953409
=====================
PARSE ERROR #1:len=20 dep=0 uid=24 oct=3 lid=24 tim=2863440953580 err=904
select dm from dual
*** 2007-04-09 10:52:57.646
=====================
PARSING IN CURSOR #1 len=81 dep=0 uid=24 oct=3 lid=24 tim=2863469576374 hv=1927069963 ad='2f084794'
select * from dual where dummy=
(select 1 from dual union all select 2 from dual)
END OF STMT
PARSE #1:c=0,e=2222,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=2863469576353
EXEC #1:c=0,e=108,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=2863469576843
FETCH #1:c=0,e=160,p=0,cr=3,cu=0,mis=0,r=0,dep=0,og=4,tim=2863469577141
STAT #1 id=1 cnt=0 pid=0 pos=1 obj=0 op='FILTER  '
=====================
PARSING IN CURSOR #2 len=116 dep=1 uid=0 oct=3 lid=0 tim=2863489522417 hv=431456802 ad='2ff628a8'
select o.owner#,o.name,o.namespace,o.remoteowner,o.linkname,o.subname,o.dataobj#,o.flags from obj$ o where o.obj#=:1
END OF STMT
PARSE #2:c=10000,e=1714,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=0,tim=2863489522404
EXEC #2:c=0,e=888,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2863489523795
FETCH #2:c=0,e=81,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim=2863489523978
STAT #1 id=2 cnt=1 pid=1 pos=1 obj=222 op='TABLE ACCESS FULL DUAL '
STAT #1 id=3 cnt=0 pid=1 pos=2 obj=0 op='UNION-ALL  '
STAT #1 id=4 cnt=0 pid=3 pos=1 obj=222 op='TABLE ACCESS FULL DUAL '
STAT #1 id=5 cnt=0 pid=3 pos=2 obj=222 op='TABLE ACCESS FULL DUAL '
=====================
PARSING IN CURSOR #1 len=85 dep=0 uid=24 oct=3 lid=24 tim=2863489526270 hv=2466126633 ad='2f06c730'
select * from dual where dummy=
(select '1' from dual union all select '2' from dual)
END OF STMT
PARSE #1:c=0,e=1612,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=2863489526258
EXEC #1:c=0,e=94,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=2863489526583
FETCH #1:c=0,e=237,p=0,cr=9,cu=0,mis=0,r=0,dep=0,og=4,tim=2863489526987
STAT #1 id=1 cnt=0 pid=0 pos=1 obj=0 op='FILTER  '
STAT #1 id=2 cnt=1 pid=1 pos=1 obj=222 op='TABLE ACCESS FULL DUAL '
STAT #1 id=3 cnt=2 pid=1 pos=2 obj=0 op='UNION-ALL  '
STAT #1 id=4 cnt=1 pid=3 pos=1 obj=222 op='TABLE ACCESS FULL DUAL '
STAT #1 id=5 cnt=1 pid=3 pos=2 obj=222 op='TABLE ACCESS FULL DUAL '
=====================
PARSING IN CURSOR #1 len=33 dep=0 uid=24 oct=42 lid=24 tim=2863499414887 hv=4238949625 ad='2f748900'
alter session set sql_trace=false
END OF STMT
PARSE #1:c=0,e=180,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=2863499414875
EXEC #1:c=0,e=140,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=2863499415195
...
Рейтинг: 0 / 0
09.04.2007, 04:09
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34446383
andreymx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andreymx
Участник
Владимир Бегун#2765516
Код: plaintext
1.
2.
3.
4.
5.
6.
Bug No.		2765516 
Filed		23-JAN-2003
Updated		23-JAN-2003 
Product		PL/SQL
Product Version	9.0.1.4.0
...
Fixed in Product Version	No Data

За 4 года некому было пофиксить
...
Рейтинг: 0 / 0
09.04.2007, 09:32
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34446403
Владимир Бегун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Бегун
Участник
andreymxЗа 4 года некому было пофиксить:-) Приоритет низкий, есть workaround...
...
Рейтинг: 0 / 0
09.04.2007, 09:38
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34446420
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Elic
Участник
andreymxЗа 4 года некому было пофикситьЭто древняя "фича" :)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
SQL*Plus: Release 3.3.4.0.0 - Production on Mon Apr 09 08:42:36 2007

Copyright (c) Oracle Corporation 1979,  1996 .  All rights reserved.


Connected to:
Oracle7 Server Release  7.3 .4.0.0 - Production
With the distributed, replication and parallel query options
PL/SQL Release 2.3.4.0.0 - Production

Monday    09.04.2007 08:42.  User - "SYSTEM".  Database - "ELIC".

System@Elic>; CREATE OR REPLACE PROCEDURE mytest AS
System@Elic>; BEGIN
System@Elic>;    FOR rec IN (SELECT * FROM SYS.DUAL D GROUP BY NULL)
System@Elic>;   LOOP
System@Elic>;     NULL;
System@Elic>;   END LOOP;
System@Elic>; END;
System@Elic>; /

Procedure created.

System@Elic>;
System@Elic>; exec mytest
begin mytest; end;

*
ERROR at line 1:
ORA-00979: not a GROUP BY expression
ORA-06512: at "SYSTEM.MYTEST", line 5
ORA-06512: at line 1
...
Рейтинг: 0 / 0
09.04.2007, 09:47
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #39446855
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
Почему статанализатор PLSQL не отлавливает ORA-00979 not a group by expression
...
Рейтинг: 0 / 0
01.05.2017, 10:49
| Ответить | Цитировать | Написать  
19 сообщений из 44, страница 2 из 2
  2  все
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&msg=34444127&tid=1886011]:
 0ms
get settings:
 7ms
get forum list:
 19ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 177ms
get topic data:
 13ms
get forum data:
 2ms
get page messages:
 55ms
get tp. blocked users:
 1ms
others: 206ms
total:  486ms
созд. / загр.: 486ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]