ora 06502 что за ошибка

Oracle / PLSQL: ORA-06502 Error Message

Learn the cause and how to resolve the ORA-06502 error message in Oracle.

Description

When you encounter an ORA-06502 error, the following error message will appear:

Cause

You tried to execute a statement that resulted in an arithmetic, numeric, string, conversion, or constraint error.

The common reasons for this error are:

Resolution

Let’s look at three options on how to resolve the ORA-06502 error:

In our first option, this error occurs when you try to assign a value to a numeric variable, but the value is larger than the variable can handle.

For example, if you created a procedure called TestProc as follows:

This procedure was successfully created. But when we try to execute this procedure, we will get an ORA-06502 error as follows:

The first line of the error message (ie: ORA-06502) indicates the error that occurred, while the second line of the error message (ie: ORA-06512) indicates that the error occurred at line 5 of the PLSQL code.

In this example, you’ve tried to assign a 3 digit number to a variable called v_number that can only handle 2 digits. You could correct this error by redefining the v_number variable as number(3).

And now when we execute our TestProc procedure, the ORA-06502 error has been resolved.

In our second option, this error occurs if you are trying to assign a non-numeric value to a numeric variable.

For example, if you created a procedure called TestProc as follows:

This procedure was successfully created. But when we try to execute this procedure, we will get an ORA-06502 error as follows:

In this example, the value of ‘a’ does not properly convert to a numeric value. You can correct this error by assigning the variable called v_number a proper numeric value.

And now when we execute our TestProc procedure, the ORA-06502 error has been resolved.

In our third option, this error occurs if you are trying to assign a NULL value to a NOT NULL constrained variable.

For example, if you created a procedure called TestProc as follows:

This procedure was successfully created. But when we try to execute this procedure, we will get an ORA-06502 error as follows:

In this example, you can not assign a NULL value to the variable called v_non_nullable_variable. You can correct this error removing NOT NULL from the variable declaration of the v_non_nullable_variable as follows:

Источник

Об исключениях и правилах

Автор: Стивен Фернстайн, член коллегии Oracle ACE

Где, когда и как лучше всего обрабатывать исключения

Вопрос: Недавно я узнал, что если исключение возникает в разделе объявлений блока, то раздел обработки исключений этого блока не обрабатывает его. Это кажется неверным. Почему PL / SQL работает именно так, и что это значит для моей практики программирования?

Ответ: Если исключение возникает в разделе объявлений блока, то оно распространяется во внешнюю среду необработанным.

PL / SQL ведет себя таким образом (или, если быть более точным, команда разработчиков PL / SQL решила реализовать обработку исключений именно таким образом) потому, что до тех пор пока локальные переменные и константы полностью не обработаны, программа не является жизнеспособной. Предположим, что исключение, возникшее в разделе объявлений, будет обрабатываться внутри этой подпрограммы. На что можно будет сослаться внутри раздела исключений? Ведь нельзя быть уверенным, что локальные переменные были проинициализированы.

Ключевой вопрос: как это поведение влияет на способ написания кода? Перед тем, как ответить на этот вопрос, давайте посмотрим, когда мы можем столкнуться с этой проблемой.

l_name VARCHAR2(5) := ‘STEVEN’;

l_age NUMBER := ’49 Years Old’;

То же самое правило для исключений применяется при инициализации переменных, объявленных в пакете (вне любой подпрограммы). Если исключение возникает при попытке инициализировать переменную уровня пакета, то это исключение будет распространяться необработанным за пределы пакета, даже если раздел инициализации содержит раздел обработки исключений. В такой ситуации машина PL / SQL все же регистрирует пакет как инициализированный и позволяет ссылаться на подпрограммы и переменные пакета.

Чтобы понять это, рассмотрим следующую последовательность шагов и PL / SQL операторов:

2. Листинг 1: В пакете присваивается слишком длинное значение пакетной символьной переменной.

5. FUNCTION little_name RETURN VARCHAR2;

8. PACKAGE BODY valerr

10. g_name VARCHAR2 (1) := ‘Liu’;

12. FUNCTION little_name RETURN VARCHAR2

16. END little_name;

18. DBMS_OUTPUT.put_line (‘Before I show you the name. ‘);

22. DBMS_OUTPUT.put_line ( ‘Trapped the error: ‘ // DBMS_UTILITY.format_error_stack ()

[у автора: » the exception goes unhandled «, по моему, как раз наоборот. А.Бачин ]:

ORA-06502: PL/SQL: numeric or value

error: character string buffer too small

ORA-06512: at «HR.VALERR», line 3

ORA-06512: at line 2

Этого и следовало ожидать.

27. Но когда я пытаюсь вызвать эту функцию второй раз, исключение не возбуждается:

29. 2 DBMS_OUTPUT.put_line

30. (‘Name: ‘ // Valerr.little_name);

35. PL/SQL procedure successfully completed.

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

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

Обратите внимание, что Oracle рассматривает это поведение как баг (номер 5658561). Если вы столкнулись с таким поведением и хотите, чтобы Oracle изменил его, предлагаю вам зайти на Oracle MetaLink и добавить к этому багу свое сообщение о том, как текущее поведение наносит ущерб вашему приложению.

Должна ли эта информация об обработке исключений изменить ваш способ написания кода? Я полагаю, да. Может быть иногда необходимо, чтобы исключение из раздела объявлений распространялось необработанным, хотя, вероятно, в большинстве случаев, предпочтительней перехватить исключение внутри блока и зарегистрировать информацию об ошибке.

Сделать это просто: не присваивайте переменным значения по умолчанию в разделе объявлений. Вместо этого создайте локальную процедуру инициализации и присвойте значения по умолчанию в этой процедуре. Затем вызовите процедуру инициализации в первой строке исполняемого раздела программы, тогда любое исключение можно будет обработать в этой программе. Например, вместо того, чтобы писать процедуру, подобную этой:

l_name VARCHAR2 (10) :=

l_name VARCHAR2 (10);

l_name := ‘Steven Feuerstein’;

Теперь, когда я запущу исправленную процедуру process_data, ошибка будет перехвачена и обработана, а затем снова возбуждена:

Trapped the error: ORA-06502:

PL/SQL: numeric or value error:

character string buffer too small

ORA-06502: PL/SQL: numeric or value

error: character string buffer too small

ORA-06512: at «HR.PROCESS_DATA»,

ORA-06512: at line 2

То же самое верно и для пакетов. В исправленной процедуре valerr в Листинге 2, в разделе инициализации просто вызывается процедура инициализации.

Листинг 2: В разделе инициализации вызывается процедура инициализации

1 PACKAGE BODY valerr

3 g_name VARCHAR2 (1);

5 FUNCTION little_name

10 END little_name;

12 PROCEDURE initialize

22 DBMS_OUTPUT.put_line ( ‘Trapped the error: ‘ // DBMS_UTILITY.format_error_stack ()

Теперь я должен признаться, что у меня есть два замечания относительно данного мной совета (переместить присваивание значений по умолчанию в отдельную подпрограмму инициализации). Во-первых, этому совету нельзя следовать по отношению к константам. Значения по умолчанию должны быть присвоены им во время объявления. Во-вторых, в исправленном пакете valerr (в Листинге 2) переменная g _ name объявлена в строке 3, а значение ей присваивается только в строке 15. В большинстве обычных пакетов, переменные будут также объявлены в первых строках пакета, а код инициализации будет отстоять от них на сотни, возможно, даже тысячи строк. Лично я не люблю такие расстояния.

Присваивание значений по умолчанию в той же строке, что и объявление переменной, кажется более простым для понимания. Вся информация в одном месте. Должен ли я поступиться этим удобством для чтения, чтобы улучшить обработку ошибок? Это обоснованная уступка, но здесь разумно использовать компромисс.

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

Этот подход улучшит читабельность кода, уменьшив риск возникновения необработанных исключений. Риск будет минимальным, поскольку мы обращаем достаточно внимания на свой код, когда пишем его, чтобы увидеть, что мы присваиваем значение неправильного типа или неверного размера. Например, если все переменные инициализируются литералами, то подпрограмма инициализации не понадобится (см. листинг 3).

Листинг 3: Переменные инициализируются литеральными значениями.

l_name VARCHAR2 (100) := ‘Steven Feuerstein’;

l_books_sold := book_counter.in_circulation (‘Oracle PL/SQL Programming’);

Операторы блока позволяют отложить объявление переменных до тех пор, пока они не будут использоваться в программе. Объявления «как раз вовремя» помогают избежать длинного однократного раздела объявлений в начале больших программ, которые содержат объявления для каждой переменной, используемой в программе.

Листинг 4: исправленная процедура PROCESS_DATA с оператором блока

l_name VARCHAR2 (100) := ‘Steven Feuerstein’;

Немедленное использование l_name

IF l_name IS NOT NULL

Затем я использую оператор блока, чтобы объявить l _ books _ sold

прямо в той области программы, в которой она требуется.

l_books_sold PLS_INTEGER := book_counter.in_circulation (‘Oracle PL/SQL Programming’);

IF l_books_sold > 1000

(‘Problem initializing l_books_sold!’);

l_name VARCHAR2(5) := ‘STEVEN’;

l_age NUMBER := ’49 Years Old’;

Тогда не придется ждать до запуска программы, чтобы обнаружить эту проблему.

Исходный код приложения в обработчике исключения.

Поэтому давайте согласимся, что размещать код приложения в предложении WHEN можно только для того, чтобы обработать ошибку (обычно такой код включает регистрацию и повторный вызов исключения). Справедливо заметить, что при использовании оператора SELECT INTO в исполняемом разделе, реализация этого подхода является загадкой. Значит ли это, что никогда нельзя писать SELECT INTO в своих программах? Давайте рассмотрим этот вопрос.

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

Листинг 5: Процедура PROCESS_FILE вызывает UTL_FILE.GET_LINE напрямую.

1 PROCEDURE process_file (dir_in IN VARCHAR2, file_in IN VARCHAR2)

Источник

Oracle PL/SQL •MySQL •MariaDB •SQL Server •SQLite

Базы данных

Встроенные исключительные ситуации

В этом учебном материале вы узнаете, как использовать встроенные исключительные ситуации в Oracle/PLSQL c синтаксисом и примерами.

Описание

Встроенные исключительные ситуации это исключительные ситуации, которые имеют определенные имена в PL/SQL. Они определены в стандартном пакете в PL/SQL и не могут быть определены программистом.
Oracle имеет стандартный набор встроенных исключительных ситуаций: