|
Обработка NO_DATA_FOUND в PL/SQL
|
|||
---|---|---|---|
#18+
Всем доброго времени суток! Обнаружил, что неправильно обрабатываю пустой результат select into в своих процедурах. Набросал тестовый пример, чтобы показать, что именно хочу спросить. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
set SERVEROUTPUT on call REPL.SP_TEST(1); ------------------------ Test DB250000I: Команда выполнена успешно. call REPL.SP_TEST(2); SQL0438N Программа генерирует ошибку или предупреждение с текстом диагностики: "NO_DATA_FOUND". Подскажите, как правильно переписать код, чтобы обрабатывать такую ситуацию? Алексей. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2010, 18:34 |
|
Обработка NO_DATA_FOUND в PL/SQL
|
|||
---|---|---|---|
#18+
Можно отказаться от использования select into в пользу выборки первой записи курсора, но это наворачивает код и делает его менее читабельным. Например, Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
SQL> call REPL.SP_TEST(2); Default DB250000I: Команда выполнена успешно. SQL> call REPL.SP_TEST(1); Test DB250000I: Команда выполнена успешно. Может можно как-то проще? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2010, 18:55 |
|
Обработка NO_DATA_FOUND в PL/SQL
|
|||
---|---|---|---|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2010, 11:06 |
|
Обработка NO_DATA_FOUND в PL/SQL
|
|||
---|---|---|---|
#18+
Подправлю немного Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.03.2010, 18:31 |
|
Обработка NO_DATA_FOUND в PL/SQL
|
|||
---|---|---|---|
#18+
Вот пытаюсь в строке сделать изменение, если нет строки с параметром, то создаю c нужными данными: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9.
вылетает при первом пустом значении ; Как сделать так чтобы не вылетал из цикла ? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2020, 20:39 |
|
Обработка NO_DATA_FOUND в PL/SQL
|
|||
---|---|---|---|
#18+
Используйте MERGE . Вообще, использовать процедурную логику (итерировать вручную по result set'у) - это крайне порочная практика. Есть исключения (когда, например, надо раздробить слишком большую транзакцию), но лучше оперировать data set'ами непосредственно в SQL. Это и компактней/более читаемо/проще модифицируемо, и выполнит СУБД это как правило быстрее, и поддерживать проще (особенно в долгосрочной перспективе, когда статистические характеристики данных и, соответственно, оптимальный алгоритм/план доступа к данным могут поменяться, а разработчика уже не найти). Если же очень надо использовать обработку not found логики, то это делается через CONDITION'ы и HANDLER'ы. Вот как вот здесь. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2020, 12:02 |
|
Обработка NO_DATA_FOUND в PL/SQL
|
|||
---|---|---|---|
#18+
Вот, кстати, и Том Кайт со мной согласен (:)) (для всех реляционных СУБД это справедливо): https://asktom.oracle.com/Misc/slow-by-slow.html На ту же тему: https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1205168148688 https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:73891904732164 . ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2020, 13:06 |
|
|
start [/forum/topic.php?fid=43&msg=36495606&tid=1600178]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 122ms |
0 / 0 |