|  | 
| 
Обработка 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=36517512&tid=1600178]: | 0ms | 
| get settings: | 11ms | 
| get forum list: | 15ms | 
| check forum access: | 4ms | 
| check topic access: | 4ms | 
| track hit: | 38ms | 
| get topic data: | 13ms | 
| get forum data: | 3ms | 
| get page messages: | 51ms | 
| get tp. blocked users: | 2ms | 
| others: | 14ms | 
| total: | 155ms | 

| 0 / 0 | 
