ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
25 сообщений из 44, страница 1 из 2
  1  все
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34442364
andreymx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andreymx
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CREATE OR REPLACE PROCEDURE mytest
AS
BEGIN
	FOR rec IN
	(
		SELECT	dummy, COUNT(*)
		FROM	dual
	)
	LOOP
		NULL;
	END LOOP;
END;
Компиляция процедуры происходит нормально. Работать - естественно, не работает:
Message: ORA-00937: not a single-group group function ORA-06512: at "SEB.MYTEST", line 10 ORA-06512: at line 2.
Читаем уважаемого Тома нашего Кайта:
* Статический SQL проверяется в процессе компиляции: Если в коде содержится ошибка, а процедура является действительной и может быть выполнена, то эта ошибка не имеет отношения к SQL.
Вот и думаю: где-то кто-то (т.е. я, конечно) из нас чего-то не понимает.
----------------------------------------------------------------------------------------------------
Является ли запрос
Код: plaintext
1.
SELECT	dummy, COUNT(*)
FROM	dual
верным с точки зрения SQL и PL/SQL ?
----------------------------------------------------------------------------------------------------
а вообще-то, конечно, достаёт в процессе разработки, что компилятор не ругается сразу
----------------------------------------------------------------------------------------------------
BANNER
Oracle9i Enterprise Edition Release 9.2.0.7.0 - Production
PL/SQL Release 9.2.0.7.0 - Production
"CORE 9.2.0.7.0 Production"
TNS for Solaris: Version 9.2.0.7.0 - Production
NLSRTL Version 9.2.0.7.0 - Production
----------------------------------------------------------------------------------------------------
спасибо
...
Рейтинг: 0 / 0
06.04.2007, 09:54
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34442402
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
С точки зрения синтаксиса здесь все правильно. Ведь может dummy -- это функция, возвращающая константу
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
tst> create function dum return number
   2   as begin return  1 ; end;
   3   /

Function created.

tst> select dum, count(*) from dual;

       DUM   COUNT(*)
---------- ----------
          1            1 

tst> select sysdate, count(*) from dual;

SYSDATE     COUNT(*)
--------- ----------
 06 -APR- 07            1
...
Рейтинг: 0 / 0
06.04.2007, 10:06
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34442451
Iscender
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iscender
Участник
Код: 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.
SQL> CREATE OR REPLACE PROCEDURE mytest
   2   AS
   3   BEGIN
   4      FOR rec IN
   5      (
   6              SELECT  dummy, COUNT(*)
   7              FROM    dual
   8      )
   9      LOOP
  10              NULL;
  11      END LOOP;
  12   END;
  13   /

Procedure created.

SQL> exec  mytest
BEGIN mytest; END;

*
ERROR at line  1 :
ORA- 00937 : not a single-group group function
ORA- 06512 : at "ISCANDER.MYTEST", line  4 
ORA- 06512 : at line  1 


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

Procedure created.

SQL> exec  mytest

PL/SQL procedure successfully completed.
...
Рейтинг: 0 / 0
06.04.2007, 10:22
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34442466
_spy_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_spy_
Участник
Вячеслав ЛюбомудровС точки зрения синтаксиса здесь все правильно. Ведь может dummy -- это функция, возвращающая константу
Хм.. мне казалось, что и разрешение имен происходит на этапе компиляции, а не выполнения.
...
Рейтинг: 0 / 0
06.04.2007, 10:25
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34442500
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
Ну, еще примерчик
Код: 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.
tst> sho user
USER is "U1"
tst> create function dummy return number
   2   as begin return  1 ; end;
   3   /

Function created.

tst> create procedure p1 as
   2   c1 varchar2( 10 ); c2 number;
   3   begin
   4   select dummy, count(*) into c1, c2 from dual;
   5   end;
   6   /

Procedure created.

tst> exec p1;
BEGIN p1; END;

*
ERROR at line  1 :
ORA- 00937 : not a single-group group function
ORA- 06512 : at "U1.P1", line  4 
ORA- 06512 : at line  1 


tst> create table dual as select dummy x from sys.dual;

Table created.

tst> exec p1;

PL/SQL procedure successfully completed.

tst>
...
Рейтинг: 0 / 0
06.04.2007, 10:31
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34442562
andreymx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andreymx
Участник
Не согласен, Вячеслав, с Вашими примерами.
А Вы-то в них верите? Вячеслав Любомудров
Код: plaintext
1.
tst> create table dual as select dummy x from sys.dual;
После выполнения этой строки процедура p1 пересобирается, а запрос внутри неё с точки зрения Оракла становится совершенно другим.
...
Рейтинг: 0 / 0
06.04.2007, 10:44
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34442620
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
Я к тому, что синтаксис допустимый , а проверять в момент компиляции ХП такие тонкие моменты поле это или функция/константа -- слишком накладно, пожалуй
А вот на этапе parse SQL-машина и выдаст ошибку
...
Рейтинг: 0 / 0
06.04.2007, 10:57
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34442634
TiG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TiG
Участник
andreymxНе согласен, Вячеслав, с Вашими примерами.
А Вы-то в них верите? Вячеслав Любомудров
Код: plaintext
1.
tst> create table dual as select dummy x from sys.dual;
После выполнения этой строки процедура p1 пересобирается, а запрос внутри неё с точки зрения Оракла становится совершенно другим.

Ну тогда вспомним такую фичу как процедуры с правами вызывающего - что реально будет вызываться станет известно только на момент выполнения.
А здесь дело в том, думается, что с точки зрения компилятора COUNT точно такая же функция как и все прочие, не агрегатные. Поэтому синтаксически здесь действительно совершенно корректный код. И ошибка поэтому времени исполнения - происходит только тогда, когда выполняется сама процедура, и sql-машина решает что же ей на самом деле прийдется делать с этим запросом и какие функции вызывать ;-)
...
Рейтинг: 0 / 0
06.04.2007, 11:00
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34442701
Jannny
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jannny
Участник
TiGНу тогда вспомним такую фичу как процедуры с правами вызывающего - что реально будет вызываться станет известно только на момент выполнения.Только в данном случае это совсем ни при чем...

TiGА здесь дело в том, думается, что с точки зрения компилятора COUNT точно такая же функция как и все прочие, не агрегатные.А это очень похоже, даже при уточнении через алиас, что dummy - это поле, результат не меняется.

PS: andreymxа вообще-то, конечно, достаёт в процессе разработки, что компилятор не ругается сразуПрисоединюсь, не очень приятно, что проверка пролетит мимо :(
...
Рейтинг: 0 / 0
06.04.2007, 11:15
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34442710
andreymx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andreymx
Участник
TiGНу тогда вспомним такую фичу как процедуры с правами вызывающего - что реально будет вызываться станет известно только на момент выполнения.
А здесь дело в том, думается, что с точки зрения компилятора COUNT точно такая же функция как и все прочие, не агрегатные. Поэтому синтаксически здесь действительно совершенно корректный код. И ошибка поэтому времени исполнения - происходит только тогда, когда выполняется сама процедура, и sql-машина решает что же ей на самом деле прийдется делать с этим запросом и какие функции вызывать ;-)Да, теперь согласен, всё понял
...
Рейтинг: 0 / 0
06.04.2007, 11:17
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34442728
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
Jannny TiGНу тогда вспомним такую фичу как процедуры с правами вызывающего - что реально будет вызываться станет известно только на момент выполнения.Только в данном случае это совсем ни при чем...
Именно причем
...
Рейтинг: 0 / 0
06.04.2007, 11:20
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34442740
TiG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TiG
Участник
Jannny[quot TiG]Ну тогда вспомним такую фичу как процедуры с правами вызывающего - что реально будет вызываться станет известно только на момент выполнения.Только в данном случае это совсем ни при чем...
[quot]

Это я не к приведенному выше примеру, а альтернативный пример. И по моему оночень даже в тему ;-))
...
Рейтинг: 0 / 0
06.04.2007, 11:23
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34442858
Jannny
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jannny
Участник
Вячеслав Любомудров Jannny TiGНу тогда вспомним такую фичу как процедуры с правами вызывающего - что реально будет вызываться станет известно только на момент выполнения.Только в данном случае это совсем ни при чем...
Именно причемПочему? Проверка при компиляции с правами создателя по-любому, так что ИМХо речь не о том, что Оракл не занет, что это будет поле или константа. Тем более, что если переписать:
Код: plaintext
SELECT t.dummy, COUNT(*) FROM	dual t
это ничего не изменит.. Или если у создателя, например, dummy - это процедура, а у потенциального исполнителя с правами вызывающего это функция, то компиляться же по-любому не будет. Это я к тому, что не понимаю, как в этом случае это может быть связано.
...
Рейтинг: 0 / 0
06.04.2007, 11:44
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34442907
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
?
Код: 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.
tst> sho user
USER is "U1"
tst> create procedure p1 authid current_user as
   2   c1 varchar2( 10 ); c2 number;
   3   begin
   4   select dummy, count(*) into c1, c2 from dual;
   5   end;
   6   /

Procedure created.

tst> grant execute on p1 to u2;

Grant succeeded.

tst> exec p1
BEGIN p1; END;

*
ERROR at line  1 :
ORA- 00937 : not a single-group group function
ORA- 06512 : at "U1.P1", line  4 
ORA- 06512 : at line  1 


tst> connect u2/u2@tst
Connected.
tst> create table dual as select dummy x from sys.dual;

Table created.

tst> create function dummy return number
   2   as begin return  1 ; end;
   3   /

Function created.

tst> exec u1.p1

PL/SQL procedure successfully completed.

tst>
...
Рейтинг: 0 / 0
06.04.2007, 11:51
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34442963
_spy_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_spy_
Участник
ИМХО, разговор уходит в другую плоскость. В процедурах с правами выполняющего большая часть проверок происходит во время исполнения, поэтому как раз к ней претензий нет, а вот в процедуре с правами создателя необходимые проверки производится на этапе компиляции, отсюда и возник вопрос, как же так. Так что присоединяюсь к мнению Jannny, что упоминание authid current_user здесь как-то не при чем.
...
Рейтинг: 0 / 0
06.04.2007, 12:02
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34443019
Jannny
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jannny
Участник
Вячеслав Любомудров?
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
tst> sho user
USER is "U1"
tst> create procedure p1 authid current_user as
   2   c1 varchar2( 10 ); c2 number;
   3   begin
   4   select dummy, count(*) into c1, c2 from dual;
   5   end;
   6   /
Procedure created.
И что? Если все то же происходит и без authid current_user, то с чего делается вывод, что эти вещи как-то связаны?
...
Рейтинг: 0 / 0
06.04.2007, 12:17
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34443020
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
Я бы вообще перенес эту проверку на этап выполнения
Ведь если значение поля одинаковое -- результат вполне осмысленен и верен
Ведь делается такое для scalar subquery (ORA-01427).

Может у них такое намерение и было :)
...
Рейтинг: 0 / 0
06.04.2007, 12:18
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34443043
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Elic
Участник
Поддерживаю автора темы. Меня такое поведение тоже сильно раздражает.
...
Рейтинг: 0 / 0
06.04.2007, 12:23
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34443090
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Вячеслав ЛюбомудровЯ бы вообще перенес эту проверку на этап выполнения. Ведь если значение поля одинаковое -- результат вполне осмысленен и верен
Не согласен. С точки зрения качества программного продукта (надежности, удобства сопровождения итп) крайне нежелательно иметь в коде фрагменты, которые "как правило работают, но могут стрельнуть" (скажем, в Вашем примере поменять return 1 на return dbms_random.value - и что будет?). Поэтому я однозначно предпочитаю подход "ты скажи четко и толком, что тебе надо, а всякую сомнительную неоднозначную фигню я зарублю".
...
Рейтинг: 0 / 0
06.04.2007, 12:33
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34443306
TiG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TiG
Участник
softwarer Вячеслав ЛюбомудровЯ бы вообще перенес эту проверку на этап выполнения. Ведь если значение поля одинаковое -- результат вполне осмысленен и верен
Не согласен. С точки зрения качества программного продукта (надежности, удобства сопровождения итп) крайне нежелательно иметь в коде фрагменты, которые "как правило работают, но могут стрельнуть" (скажем, в Вашем примере поменять return 1 на return dbms_random.value - и что будет?). Поэтому я однозначно предпочитаю подход "ты скажи четко и толком, что тебе надо, а всякую сомнительную неоднозначную фигню я зарублю".

Ну эта проблема вряд ли имеет отношение к качеству продукта, все таки если она есть - выстрелит при первом же тестовом запуске.
А вообще и сам периодически сталкиваюсь. Пишешь код с нуля - запросы отдельно проверяешь, дописывешь готовый - изменяешь прямо в коде, как итог иногда попадаюсь. Абыдно, да
Тем более что на этапе компиляции вся необходимая информация есть и отличить агрегатную функцию от обычной не составляет труда. Права вызывающего конечно отдельный случай, но и там тем не менее проверки доступности и т.п. объектов, используемых в коде, проводятся на этапе компиляции. И это правильно - чем раньше трабл найдем, тем быстрее исправим ;-)
...
Рейтинг: 0 / 0
06.04.2007, 13:21
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34443414
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
Быть может, по обыкновению скажу несусветную глупость, но мне представляется, что при компиляции PL/SQL кода парсинга SQL-запросов не происходит. Поэтому проверки проверками, а данная ошибка - runtime.
...
Рейтинг: 0 / 0
06.04.2007, 13:47
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34443754
bl_beard
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bl_beard
Участник
andrey_anonymousБыть может, по обыкновению скажу несусветную глупость, но мне представляется, что при компиляции PL/SQL кода парсинга SQL-запросов не происходит. Поэтому проверки проверками, а данная ошибка - runtime.

не ну я конечно понимаю самокритика в ответ включена, но все равно подумать нужно было над тем что пишешь, а еще лучше попробовать:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
SQL> edit
Wrote file afiedt.buf

   1   CREATE OR REPLACE procedure test_pr is
   2   begin
   3       select count("bla-bla") from dual;
   4 * end;
SQL> /

Warning: Procedure created with compilation errors.

SQL> show errors;
Errors for PROCEDURE TEST_PR:

LINE/COL ERROR
-------- -----------------------------------------------------------------
 3 / 5       PL/SQL: SQL Statement ignored
 3 / 18      PL/SQL: ORA- 00904 : "bla-bla": invalid identifier
SQL>

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

пс "оно" - это Оракл. :)
...
Рейтинг: 0 / 0
06.04.2007, 14:59
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34443962
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
bl_beard
Код: plaintext
1.
2.
3.
4.
-------- -----------------------------------------------------------------
 3 / 5       PL/SQL: SQL Statement ignored
 3 / 18      PL/SQL: ORA- 00904 : "bla-bla": invalid identifier
SQL>

как несложно понять из этого примера парсинг запроса таки произошел и
откровенную лажу, типа доступа к полям, которых
действительно нет в таблице оно все таки выщемило.
Так где парсинг-то?
...
Рейтинг: 0 / 0
06.04.2007, 15:49
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34444001
Andrew Max
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrew Max
Участник
При выполнении DDL оператора (CREATE OR REPLACE) парсинг, безусловно, происходит.
Но следующий пример показывает, что даже парсинг анонимного блока не вызывает ошибок, в то время как парсинг отдельного SQL-запроса приводит к ORA-00937:

Код: 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.
SQL> declare
   2     c number;
   3   begin
   4     c := dbms_sql.open_cursor;
   5     dbms_sql.parse
   6       (c,
   7       'BEGIN
  8      FOR REC IN
  9      (
 10        SELECT A."DUMMY", COUNT(*) FROM SYS.DUAL A
 11      )
 12      LOOP
 13        NULL;
 14      END LOOP;
 15      END;',
  16       dbms_sql.native);
  17     dbms_sql.close_cursor(c);
  18   exception
  19     when others then
  20       if dbms_sql.is_open(c) then
  21         dbms_sql.close_cursor(c);
  22       end if;
  23       raise;
  24   end;
  25   /

Процедура PL/SQL успешно завершена.

SQL> declare
   2     c number;
   3   begin
   4     c := dbms_sql.open_cursor;
   5     dbms_sql.parse
   6       (c,
   7       'SELECT A."DUMMY", COUNT(*) FROM SYS.DUAL A',
   8       dbms_sql.native);
   9     dbms_sql.close_cursor(c);
  10   exception
  11     when others then
  12       if dbms_sql.is_open(c) then
  13         dbms_sql.close_cursor(c);
  14       end if;
  15       raise;
  16   end;
  17   /
declare
*
ошибка в строке  1 :
ORA- 00937 : групповая функция не является одногруппной
ORA- 06512 : на  line  15 


SQL>
...
Рейтинг: 0 / 0
06.04.2007, 16:03
| Ответить | Цитировать | Написать  
Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
    #34444066
Фотография Timm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Timm
Участник
Andrew MaxПри выполнении DDL оператора (CREATE OR REPLACE) парсинг, безусловно, происходит.
Но следующий пример показывает, что даже парсинг анонимного блока не вызывает ошибок, в то время как парсинг отдельного SQL-запроса приводит к ORA-00937:
...
Не понимаю, в чем может быть разница при парсинге анонимного/хранимого PL-блоков? Для чего этот пример? :)
...
Рейтинг: 0 / 0
06.04.2007, 16:16
| Ответить | Цитировать | Написать  
25 сообщений из 44, страница 1 из 2
  1  все
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Кривой вопрос в пятницу: PL-SQL, групповые функции, статический SQL, Том Кайт
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&msg=34443019&tid=1886011]:
 0ms
get settings:
 9ms
get forum list:
 16ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 204ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 71ms
get tp. blocked users:
 2ms
others: 242ms
total:  565ms
созд. / загр.: 565ms
x
x
Закрыть


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