Буфер символьных строк слишком маленький ошибка числа или значения что это
ORA-06502: PL/SQL: числовая ошибка или ошибка значения: буфер символьной строки слишком мал
Я пробовал следующий код разными способами, например, вынимая while или if, но когда я собираю оба вместе (if и while), я всегда получаю ошибку в конце.
FIXED изменив способ объявления переменной «a» на:
*Notice что здесь существенным изменением является использование VARCHAR2 вместо CHAR (не большей длины). Согласно ответу @user272735, это ключ.
3 ответа
Я часто получаю эту ошибку (это так раздражает!): Отчет об ошибке: ORA-06502: PL/SQL: числовая ошибка или ошибка значения: буфер символьной строки слишком мал ORA-06512: в строке 305 06502. 00000-PL/SQL: числовое или значение error%s Пример хранимой процедуры заключается в циклическом переборе.
У меня возникли проблемы с этим простым запросом в oracle application express и я получаю эту ошибку: Запрос не может быть проанализирован, пожалуйста, проверьте синтаксис вашего запроса. (ORA-06502: PL/SQL: числовая ошибка или ошибка значения: буфер символьной строки слишком мал) SELECT.
PL/SQL: числовая ошибка или ошибка значения: буфер символьной строки слишком мал
это связано с тем, что вы объявляете строку фиксированной длины (скажем, 20), и в какой-то момент в вашем коде вы присваиваете ей значение, длина которого превышает то, что вы объявили.
будет ли срабатывать такая ошибка
Это также может произойти, если в вашем файле csv есть ошибочное или случайное уравнение. то есть одна из ячеек в вашем файле csv начинается со знака равенства (=) (уравнение excel), что, в свою очередь, приведет к ошибке. Если вы исправите или удалите это уравнение, избавившись от знака равенства, оно должно решить ошибку ORA-06502.
Похожие вопросы:
На моей странице asp.net возвращено ORA-06502: PL/SQL: ошибка числового или значимого значения: буфер символьной строки слишком мал. но в toad году все идет хорошо. это мой oracle-процессуального.
Я часто получаю эту ошибку (это так раздражает!): Отчет об ошибке: ORA-06502: PL/SQL: числовая ошибка или ошибка значения: буфер символьной строки слишком мал ORA-06512: в строке 305 06502.
У меня возникли проблемы с этим простым запросом в oracle application express и я получаю эту ошибку: Запрос не может быть проанализирован, пожалуйста, проверьте синтаксис вашего запроса.
Вот код. это не полный код. Я обрезал его до того места, где произошла первая ошибка: FUNCTION get ( p_sql_o OUT VARCHAR2 ) RETURN VARCHAR2 AS str_sql VARCHAR2(4000); BEGIN str_sql := ‘ SELECT *.
Я совершенно ошеломлен и не понимаю, что мне нужно сделать, чтобы исправить эту ошибку. У меня есть процедура plsql, которая принимает строку varchar2 и параметр OUT, который является числом. Можете.
ORA-06502: буфер строки символов слишком мал. Даже если размер строки ниже заявленного ограничения размера
Об этой ошибке: ORA-06502: числовая или значимая ошибка
Переменная обозначается как
Переменная v_field_A не может содержать значение более 100 символов.
Почему нет? Это очень возможно, так как вы сцепление переменная для каждой строки в КУРСОР ДЛЯ ПЕТЛИ.
Использовать DBMS_OUTPUT чтобы увидеть текущий размер переменной и добавляемое новое значение.
Давайте отладим
ошибка
Что мне не хватает?
Также остерегайтесь символов вместо байтов. В varchar2 каждый CHARACTER, вероятно, займет 2 байта.
Проверьте, сколько раз это условие выполняется и какие значения объединяются. Поскольку это объединяется несколько раз, существует вероятность того, что размер v_field_A превышает 50 символов.
Чтобы решить эту проблему, вы можете увеличить размер этой переменной. Вы можете объявить varchar размером до 32 767 байт
Вы можете выполнить конкатенацию строк в SQL-запросе:
Это сделано для упрощения вашего кода. Вы по-прежнему ограничены длиной строки Oracle. Вы можете обойти ограничение Oracle в PL / SQL с помощью CLOB, но в этом нет необходимости, если конечная строка состоит всего из нескольких сотен символов.
Ответ на ваш вопрос заключается в том, сколько раз цикл выполняется и сколько раз он входит в условие IF.
ПРИМЕР :
Состояние : МЕЖДУ 4 А ТАКЖЕ 8
Количество выполнений цикла = 100
Из-за КОНКАТИНАЦИЯ размер определенно вырастет более чем на 100 символов.
То же самое будет и с другими условиями LOOP.
Решение : Попробуйте использовать CLOB вместо того VARCHAR чтобы устранить эту проблему.
Ошибки Oracle очень наглядны. Если он вызывает ошибку, это в значительной степени объясняет сценарий: P.
ORA-06502: буфер строки символов слишком мал. Даже если размер строки ниже заявленного ограничения размера
Переменная объявлена как
5 ответов
Переменная v_field_A не может содержать значение более 100 символов.
Давайте отладим
Ошибка
Что мне не хватает?
Также остерегайтесь символов вместо байтов. В varchar2 каждый CHARACTER, вероятно, займет 2 байта.
Проверьте, сколько раз это условие выполняется и какие значения объединяются. Поскольку это объединяется несколько раз, существует вероятность того, что размер v_field_A превышает 50 символов.
Чтобы решить эту проблему, вы можете увеличить размер этой переменной. Вы можете объявить varchar размером до 32 767 байт
Ответ на ваш вопрос заключается в том, сколько раз цикл выполняется и сколько раз он входит в условие IF.
ПРИМЕР:
Количество повторений цикла = 100.
Из-за СВЯЗИ размер определенно превысит 100 символов.
То же самое будет и с другими условиями LOOP.
Ошибки Oracle очень наглядны. Если он вызывает ошибку, это в значительной степени объясняет сценарий: P.
Вы можете выполнить конкатенацию строк в SQL-запросе:
Это сделано для упрощения вашего кода. Вы по-прежнему ограничены длиной строки Oracle. Вы можете обойти ограничение Oracle в PL / SQL с помощью CLOB, но в этом нет необходимости, если конечная строка состоит всего из нескольких сотен символов.
Буфер символьных строк слишком маленький ошибка числа или значения что это
В чем может быть причина такой ошибки?
ORA-06502: PL/SQL: numeric or value error: character string buffer too small
И где можно увеличить этот character string buffer?
ORA-06502 PL/SQL: numeric or value errorstring
An arithmetic, numeric, string, conversion, or constraint error occurred. For example, this error occurs if an attempt is made to assign the value NULL to a variable declared NOT NULL, or if an attempt is made to assign an integer larger than 99 to a variable declared NUMBER(2).
Change the data, how it is manipulated, or how it is declared so that values do not violate constraints.
← →
Desdechado © ( 2006-11-13 13:14 ) [2]
← →
SergP © ( 2006-11-13 13:27 ) [3]
Понял.
Теперь как бы найти в каком месте это происходит, а то процедура большая, а в логе выводится только номер строки где raise стоит.
> [3] SergP © (13.11.06 13:27)
В PL/SQL Developere например есть отладчик процедур.
смысл такого
EXCEPTION
WHEN OTHERS
THEN
RAISE;
END;
обработчика?
без него тебе бы и строку показало
← →
ANB © ( 2006-11-13 13:34 ) [6]
> SergP © (13.11.06 13:27) [3]
Хех. Известный косяк. Сохраняй на всех перехватах исключений ее трассировку. так сможешь найти место ошибки. И сделай все варчаровые переменные подлиннее. Оракл сильно от этого не напряжется. Кстати, возможный вариант, из-за чего может появится ошибка :
имеем S varchar2(10). S := «Вася123456»; На 10-ке (XE) вполне вероятна ошибка невлезания, т.к. русские буквы занимают по 2 байта. Лечится заменой varchar2(10) на varchar2(10 char)
← →
SergP © ( 2006-11-13 13:49 ) [7]
Спасибо. Убрал этот обработчик и нашел где.
← →
Desdechado © ( 2006-11-13 13:52 ) [8]
> русские буквы занимают по 2 байта
Это если NVARCHAR2 пытаться туда запихнуть. Или нет?
← →
SergP © ( 2006-11-13 14:01 ) [9]
> [8] Desdechado © (13.11.06 13:52)
> > русские буквы занимают по 2 байта
> Это если NVARCHAR2 пытаться туда запихнуть. Или нет?
там оказалось что не с русскими буквами связано, а с цифрами.
видимо число не влазило в
v_n_reg_sa VARCHAR2 (20) := NULL;
увеличил на глаз до 24. Теперь работает.
> Это если NVARCHAR2 пытаться туда запихнуть. Или нет?
Не. Просто константу. Причем на 9-ке с этим проблем не было.
← →
SergP © ( 2006-11-13 15:24 ) [11]
> [9] SergP © (13.11.06 14:01)
>
> увеличил на глаз до 24. Теперь работает.
Блин. Разработчики редиски. Сегодня прислали версию, вместо той что раньше прислали. Посмотрел, а они там уже сами увеличили размеры переменных. А я часа 1,5-2 потратил на поиск этих «багов».
← →
Desdechado © ( 2006-11-13 16:09 ) [12]
> Не. Просто константу. Причем на 9-ке с этим проблем не было.
В какой кодировке создавалась БД? В какой кодировке схема? Может, умолчания изменились?
← →
k2 © ( 2006-11-13 16:12 ) [13]
Desdechado © (13.11.06 16:09) [12]
для nls_length_semantics умолчание изменилось вроде:
в 9-ке-char, в 10-ке-byte
← →
ANB © ( 2006-11-13 16:13 ) [14]
> Desdechado © (13.11.06 16:09) [12]
ЭЭЭЭ. Просто пнули XE она сама все поставила. Не задавая лишних вопросов. Хотя, в принципе, указание размерности никому не мешает, зато код будет работать при любой настройке базы.
> Хотя, в принципе, указание размерности никому не мешает,
> зато код будет работать при любой настройке базы.
← →
Desdechado © ( 2006-11-13 16:32 ) [16]
Да, доменов мне не хватает.
← →
k2 © ( 2006-11-13 16:35 ) [17]
Desdechado © (13.11.06 16:32) [16]
знач наврала сорри, у меня это запросто 🙂
← →
ANB © ( 2006-11-13 16:43 ) [18]
> Desdechado © (13.11.06 16:32) [16]
Не, это из-за кодировки. Почему то в XE по дефолту полуторнобайтовая кодировка врублена (не помню как она называется, однако dump хорошо это показывает).
← →
Игорь Шевченко © ( 2006-11-13 17:21 ) [19]
ANB © (13.11.06 16:43) [18]
> Почему то в XE по дефолту полуторнобайтовая кодировка врублена
А это я вполне могу вечером посмотреть, стоит XE с кодировкой по умолчанию. XE юникодный (XEUniv)
← →
Игорь Шевченко © ( 2006-11-13 22:55 ) [20]
В XE без всяких исправлений, как было, так и встало.
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
← →
ANB © ( 2006-11-14 10:37 ) [21]
NLS_CHARACTERSET AL32UTF8
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CHARACTERSET AL16UTF16
Вот эти параметры намекают мне, что у тебя по идее должна быть такая же проблема, если явно не указать размерность char
← →
Игорь Шевченко © ( 2006-11-14 11:09 ) [22]
ANB © (14.11.06 10:37) [21]
> Вот эти параметры намекают мне, что у тебя по идее должна
> быть такая же проблема, если явно не указать размерность
> char
Безусловно. Я указываю char в объявлении полей, когда допускаю, что в полях будут находиться символы, отличные от #0-#127, а гады говорят, что надо устанавливать nls_length_semantics для базы, а в объявлениях ничего не трогать.
← →
ANB © ( 2006-11-14 11:18 ) [23]
> Игорь Шевченко © (14.11.06 11:09) [22]
Уй млин. А мы в базе не стали указывать. Только в хранимках. Хотя я просто все символьные поля, кроме особых случаев, сделал по 4000 байт и забил. Так что по идее влезет все.
← →
ANB © ( 2006-11-14 11:19 ) [24]
← →
Игорь Шевченко © ( 2006-11-14 11:45 ) [25]
ANB © (14.11.06 11:18) [23]
> Хотя я просто все символьные поля, кроме особых случаев,
> сделал по 4000 байт и забил. Так что по идее влезет все.
>
«The BYTE and CHAR qualifiers override the semantics specified by the NLS_LENGTH_SEMANTICS parameter, which has a default of byte semantics. For performance reasons, Oracle recommends that you use the NLS_LENGTH_SEMANTICS parameter to set length semantics and that you use the BYTE and CHAR qualifiers only when necessary to override the parameter«
«Oracle® Database SQL Reference
10g Release 1 (10.1)
Part Number B10759-01″
← →
ANB © ( 2006-11-14 11:57 ) [26]
← →
Игорь Шевченко © ( 2006-11-14 12:16 ) [27]
> Ну и сделал бы столько 🙂 На размер БД это не влияет. Они
> же варчаровые.
Наверное ты Celko не читал. А зря, он как раз очень аргументированно возражает против такого бездумного назначения максимального размера полям.
Рекомендую: http://www.mini-mag.ru/?cid=2170&tov=163372
← →
ANB © ( 2006-11-14 12:20 ) [28]
← →
k2 © ( 2006-11-14 12:24 ) [29]
и мы даже знаем кто 🙂
только Селко наверное тож пару раз проектами рулил 🙂
← →
Игорь Шевченко © ( 2006-11-14 12:59 ) [30]
ANB © (14.11.06 12:20) [28]
Авторитет авторитету люпус эст.
Особенно в SQL*Plus удобно запросы с такими полями делать.
← →
ANB © ( 2006-11-14 13:04 ) [31]
← →
Игорь Шевченко © ( 2006-11-14 13:12 ) [32]
ANB © (14.11.06 13:04) [31]
> Я тоадом пользуюсь. он под ширину данных ширину колонки
> подгоняет
если там пара сотен тысяч записей.
Кроме того, извини, когда жаба будет поставляться в дистрибутиве оракла, тогда имеет смысл говорить, что ты ей пользуешься и всем рекомендуешь. Тора, она хоть бесплатная, но тормозная, а жаба денег стоит и потому давит.
Вот и остается SQL*Plus
← →
ANB © ( 2006-11-14 15:48 ) [33]
← →
Игорь Шевченко © ( 2006-11-14 16:18 ) [34]
ANB © (14.11.06 15:48) [33]
Про жабу интересно написано:
«The Toad Freeware version may be used for a maximum of five (5) users within Licensee»s organization and expires each sixty (60) days, after which you will need to download and install the product again»
http://www.toadsoft.com/lic_agree.html
Насколько я знаю, бесплатная TORA ну и SQL*Plus 🙂
← →
k2 © ( 2006-11-14 16:40 ) [35]
ANB © (14.11.06 13:04) [31]
Андрей, а твоя жаба оракловые пакеты понимает на десятке? и какая тогда версия?
← →
ANB © ( 2006-11-14 17:08 ) [37]
← →
k2 © ( 2006-11-14 17:20 ) [38]
← →
ANB © ( 2006-11-14 17:30 ) [39]
← →
k2 © ( 2006-11-14 17:36 ) [40]
у меня 10.2.0.2
кстати если прихъодилось жабу под mssql-ем гонять пристойно себя ведет?
← →
Игорь Шевченко © ( 2006-11-14 17:42 ) [41]
k2 © (14.11.06 17:20) [38]
ANB © (14.11.06 17:30) [39]
Val © (14.11.06 17:02) [36]
> да вроде %TYPE неплохо справляется.
← →
k2 © ( 2006-11-14 17:57 ) [42]
>[41] Игорь Шевченко © (14.11.06 17:42)
зачем?
← →
Игорь Шевченко © ( 2006-11-14 18:03 ) [44]
Val © (14.11.06 17:57) [43]
Ну чтобы домен был.
Оно ж как мыслится:
CREATE DOMAIN DFOO CHAR(3) DEFAULT «BAR» NOT NULL
CHECK (DFOO IN («BAR», «BAZ», «BOO»));
а в объявлении таблицы пишешь просто
CREATE TABLE FOOTABLE (
.
FOO DFOO,
.
);
← →
Игорь Шевченко © ( 2006-11-14 18:04 ) [45]
k2 © (14.11.06 17:57) [42]
То ж небось для самого дизайнера.
>[42] k2 © (14.11.06 17:57)
Здесь под доменом понимается определенный пользователем тип, который может быть и типом поля таблицы. Такого в Оракле пока я не встретил.
← →
ANB © ( 2006-11-14 18:48 ) [48]
>ANB © (14.11.06 18:48)
поля с объектыми типами? может, таблицы объектного типа?
← →
Desdechado © ( 2006-11-14 19:09 ) [50]
Val © (14.11.06 19:02) [49]
и поля объектных типов тоже
>[50] Desdechado © (14.11.06 19:09)
речь о вложенных таблицах?
← →
Desdechado © ( 2006-11-14 20:41 ) [52]
Val © (14.11.06 19:17) [51]
нет, например:
CREATE TABLE TUNE(
REGION_ID NUMBER(10) NOT NULL,
SDO_MIN_RECT MDSYS.SDO_GEOMETRY,
SDO_DIMINFO MDSYS.SDO_DIM_ARRAY
);
← →
Игорь Шевченко © ( 2006-11-15 10:27 ) [53]
Val © (14.11.06 18:22) [47]
Мне просто лень писать каждый раз одни и те же проверки. И лень потом исправлять во многих местах, если DOMAIN изменился по какой-то причине.
>Desdechado © (14.11.06 20:41)
MDSYS.SDO_GEOMETRY
и
MDSYS.SDO_DIM_ARRAY
не являются таблицами по сути?