Ориентация перемещаемого курсора

Вследствие того, что в SQL курсор может быть перемещаемым, помимо NEXT можно использовать и другие значения параметра ориентации. После перемещения с ориентацией PRIOR курсор перемещается к предыдущей строке. В случае ориентации FIRST курсор перемещается к первой записи, а в случае ориентации LAST – к последней записи выборки.

Задание ориентации в виде числа требует присутствия команд ABSOLUTE и RELATIVE. Например, FETCH ABSOLUTE 7 перемещает курсор на седьмую строку от начала выборки. FETCH RELATIVE 7 перемещает курсор на семь строк ниже его текущей позиции. FETCH RELATIVE 0 не перемещает курсор.

Оператор FETCH RELATIVE 1 производит такое же действие, что и FETCH NEXT; FETCH RELATIVE-1 действует таким же образом, что и FETCH PRIOR; FETCH ABSOLUTE 1 выбирает первую запись; FETCH ABSOLUTE 2 – вторую запись и т.д. Аналогично, FETCH ABSOLUTE – 1 предоставляет последнюю запись, a FETCH ABSOLUTE – 2 – предшествующую последней записи выборки и т.д. Оператор FETCH ABSOLUTE 0 генерирует исключение отсутствия данных, таким же образом действует FETCH ABSOLUTE 17, если в выборке только 16 строк. Оператор FETCH <спецификация_простого_значения> возвращает запись, заданную спецификацией простого значения.

Позиционные операторы DELETE и UPDATE

Со строками, на которые в данный момент указывает курсор, можно выполнять операции удаления и обновления. Синтаксис оператора DELETE следующий:

DELETE FROM имя_таблицы WHERE CURRENT OF имя_курсора;

Если курсор не указывает на строку, генерируется ошибка, и удаление не происходит. Вот синтаксис оператора UPDATE:

UPDATE имя_таблицыSET имя_столбца = значение [,имя_столбца = значение]…WHERE CURRENT OF имя_курсора;

Значение, помещаемое в каждый выбранный столбец, должно являться выражением, ключевым словом или ключевым словом DEFAULT. Если при проведении операции обновления возникает какая-либо ошибка, обновление не выполняется.

Закрытие курсора

Совет:
Закончив работу с курсором, тут же закройте его. Курсоры, оставшиеся открытыми после того, как приложение закончило свою работу с ними, как правило, безобидны, но опять-таки не всегда. Кроме того, открытые курсоры используют системные ресурсы.

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

 

Постоянно хранимые модули

В этой главе…

· Сложные команды, атомарность, курсоры, переменные и состояния

· Управляющие структуры

· Создание циклов

· Использование хранимых процедур и функций

· Предоставление полномочий на выполнение

· Создание и использование хранимых модулей

В течение многих лет ведущие специалисты в области технологий баз данных работали над разработкой стандартов. После выхода очередного стандарта и начала его применения пользователями и программистами во всем мире сразу начинается процесс разработки следующего. Так было и в случае SQL-92. Семь лет разделяет выпуск SQL-92 и выход первого компонента SQL: 1999. Однако все эти годы продолжалась кипучая деятельность, в результате которой ANSI и ISO выпустили дополнение к SQL-92, названное SQL-92/PSM (Persistent Stored Modules – постоянно хранимые модули). Это дополнение послужило основой для одного из разделов стандарта SQL: 1999 с тем же названием. SQL/PSM как часть SQL:2003 определяет набор операторов, предоставляющих SQL возможности по созданию управляющих структур, обычных для наиболее мощных языков программирования. Благодаря этому стало возможным решать многие задачи только с использованием SQL, без привлечения других программных средств. Предыдущие версии SQL требовали непрерывного переключения между SQL и процедурным базовым языком.

Составные команды

В этой книге SQL рассматривается как непроцедурный язык, который применяется в основном для обработки наборов данных, а не отдельных записей. В то же время в этой главе вы узнаете, что это положение постепенно меняется. SQL становится процедурным языком, в основных чертах все еще оставаясь средством для обработки наборов данных. Версия SQL, определяемая стандартом SQL-92, не соответствовала процедурной модели, в которой команды выполняются одна за другой в определенной последовательности. Команды SQL были одиночными и, как правило, встроенными в код программы C++ или Visual Basic. Фактически с помощью ранних версий SQL пользователи не могли создать запрос или выполнить некоторые другие операции с помощью последовательности операторов SQL. Выполнение же последовательности команд SQL вызывало значительное снижение производительности. Каждая выполняющаяся команда SQL должна послать сообщение с места работы пользователя на сервер баз данных, а тот должен отослать ответ в обратном направлении. Это увеличивает сетевой обмен и тем самым приводит к дополнительной нагрузке на сеть.

SQL: 1999 и SQL:2003 предоставляют возможность создания составных команд, образованных отдельными командами SQL, выполняемыми в один прием. Использование составных команд позволяет снизить загрузку сети, поскольку все отдельные команды, образующие составную, вместе пересылаются на сервер, возвращающий обратно один ответ.

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

void main {EXEC SQLBEGININSERT INTO students (StudentID, Fname, Lname)VALUES (:sid,:sfname,:sid);INSERT INTO roster (ClassID, Class, StudentID)VALUES (:cid, rename,:sid);INSERT INTO receivable (StudentID, Class, Fee)VALUES (:sid,:cname,:cfee);END;/* Проверка значения SQLSTATE на код ошибки */}

Приведенный выше небольшой фрагмент программы на языке С содержит встроенную составную команду SQL. Комментарии относятся к обработке ошибок. Если почему-то составная команда не выполнилась, в специальный параметр SQLSTATE будет помещен код ошибки. Понятно, что комментарий не может обработать ошибку. Я поместил его лишь с целью напомнить о том, что в реальной программе код обработки ошибок находится в этом месте.

Атомарность

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

Что в имени твоем?

Название дополнения SQL – постоянно хранимые модули (persistent stored modules) – очень метко описывает их назначение.

Да вы уже и сами могли догадаться. Если слово модуль вам неизвестно, освежите в памяти материал главы 15. По логике хранимый модуль должен являться чем-то таким, что находится в некотором месте до тех пор, пока не потребуется. Кроме того, постоянно хранимый модуль должен быть чем-то, что находится под рукой в течение определенного периода времени. Вот, собственно, и все, о чем рассказывается в этой главе.

Вы почти угадали, хотя логика немного увела вас в сторону. В этой главе описываются подобные модули. Но постоянно хранимые модули больше связаны с другими возможностями SQL. В SQL:2003 огромное количество постоянно хранимых модулей содержат необходимые функции, которые следовало включить еще в SQL-92, но этого не произошло. Такие функции значительно повышают мощность и полезность SQL, и они должны были где-то находиться. Некоторые из них действительно хранятся под своими именами (в частности, хранимые функции и хранимые процедуры). Ладно, довольно логики. Важно лишь, что эти новые средства существуют и работают.

Что если операции вставки в таблицы Students (студенты) и Roster (расписание) произошли, а в результате вмешательства постороннего пользователя операция вставки в таблицу Receivable (плата за учебу) не выполнилась. Получится, что студент будет зачислен, но счет за обучение ему выписан не будет. Такие ошибки могут слишком дорого обойтись университету. Для предотвращения развития событий по данному сценарию необходимо ввести концепцию атомарности. Атомарная команда является неделимой. Она либо выполняется целиком, либо не выполняется вовсе. Простые команды SQL атомарны по своей природе. Другое дело – составные команды SQL. Однако и составную команду тоже можно определить атомарной. В приведенном ниже примере составная команда SQL становится безопасной благодаря введению атомарности.

void main {EXEC SQLBEGIN ATOMICINSERT INTO students (StudentID, Fname, Lname)VALUES (:sid,:sfname,:sid);INSERT INTO roster (ClassID, Class, StudentID)VALUES (:cid,:cname,:sid);INSERT INTO receivable (StudentID, Class, Fee)VALUES (:sid,:cname,:cfee);END;/* Проверка значения SQLSTATE на код ошибки */}

Ключевые слова ATOMIC после BEGIN гарантируют выполнение всей команды полностью, а в случае возникновения ошибки происходит откат к исходному состоянию базы данных.

Переменные

Все высокоуровневые языки программирования, такие как С или Basic, позволяют использовать переменные. До появления SQL/PSM переменные в SQL использовать было нельзя. Переменные являются символическими именами значений определенного типа. В составных командах можно объявить переменную и определить ее значение. В ходе выполнения составной команды переменная может использоваться. После завершения выполнения составной команды все переменные, объявленные в ней, уничтожаются. Таким образом, переменные в SQL являются локальными переменными составной команды, в которой они объявлены. Рассмотрим следующий пример:

BEGINDECLARE prezpay NUMERIC;SELECT salaryINTO prezpayFROM EMPLOYEEWHERE jobtitle= 'president';END;

Курсоры

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

BEGINDECLARE ipocandidate CHARACTER (30);DECLARE cursorl CURSOR FORSELECT companyFROM biotech;OPEN cursor1;FETCH cursor1 INTO ipocandidate;CLOSE cursor1;END;

Состояния

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

Каждый раз, когда выполняется команда SQL, сервер базы данных обновляет значение параметра статуса SQLSTATE. Он представляет собой поле из пяти символов. Значение SQLSTATE содержит информацию об успешном или неудачном завершении команды. В случае возникновения ошибки значение содержит ее код.

Первые два из пяти символов значения класса SQLSTATE содержат информацию о том, выполнены ли команды SQL успешно, непонятно как или неудачно. В табл. 19.1 приведены четыре возможных результата.

Таблица 19.1. Значения класса sqlstate.

Класс	Описание
00	Успешное завершение
01	Предупреждение
02	Не найден
Другое	Сгенерировано исключение

Значение класса '00' означает, что предыдущая команда SQL выполнена успешно. В большинстве случаев это наиболее желаемый результат.

Значение класса '01' означает предупреждение. Предупреждение указывает на то, что в ходе выполнения команды SQL случилось что-то незапланированное. В данном случае СУБД не "знает", произошла ошибка или нет. Предупреждение обращает внимание разработчика на то, что требуется тщательно проверить команду SQL.

Значение класса '02' означает, что не получено никаких данных в результате выполнения команды SQL. Это может быть хорошим или плохим известием, в зависимости от обстоятельств. Иногда результат в виде пустой таблицы – как раз то, что требуется разработчику.

Любой код, отличный от значений '00', '0Г или '02', указывает на наличие ошибки в программе. Три последних символа параметра SQLSTATE содержат код ошибки. Два символа кода класса и три символа кода ошибки вместе составляют пять символов значения SQLSTATE.

Обработка состояний

Программу можно написать таким образом, чтобы значение параметра SQLSTATE контролировалось после выполнения каждой команды SQL. Итак, используем приобретенные знания на практике.

· При получении сообщения кода класса '00' вряд ли необходимо предпринимать дополнительные действия. Продолжайте делать то, что вы планировали.

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

· Получение какого-либо другого класса кода указывает на то, что в программе имеются ошибки. В этом случае следует перейти к процедуре обработки исключения. Конкретная процедура, на которую должно перейти выполнение программы, зависит от содержимого параметра SQLSTATE. Если существует возможность множества различных состояний, для каждого следует использовать собственную процедуру обработки, так как различные состояния часто должны обрабатываться по-разному. Некоторые ошибки несущественны или поправимы. Другие являются фатальными и приводят к аварийному завершению приложения.