)
Источники: печатная документация и справочная информация по Borland InterBase, переписка листсервера esunix1.
последние изменения: 2 июля 1999.
Большинство SQL-серверов имеет специальные механизмы для создания уникальных идентификаторов. В Borland Interbase для этого существует механизм генераторов.
В данной статье будут рассмотрены следующие темы:
Создание генераторов
Получение текущего значения генератора
Удаление генераторов
Создание генераторов
Генератор - это специальный объект базы данных, который генерирует уникальные последовательные числа. Эти числа могут быть использованы в качестве идентификаторов (например код клиента, номер счета и т.п.). Для создания генератора необходимо использовать оператор DDL
CREATE GENERATOR generatorname;
При выполнении такой команды происходит 2 действия:
1. На специальной странице БД отводится 4 байта для хранения значени генератора
2. В системной таблице RDB$GENERATORS заводится запись, куда помещаетс имя генератора иего номер (фактически смещение на странице генераторов).
После создания генератора его значения можно получать при помощи функции
GEN_ID(generatorname, inc_value)
где inc_value - число, на которое необходимо прирастить значение генератора.
Генераторы возвращают значения (и сохраняют свои значения на диске) вне контекста транзакции пользователя. Это означает, что если генератора было увеличено с 10 до 11 (инкремент 1), то даже при откате транзакции (ROLLBACK) значение генератора не вернется к предыдущему. Вместе с этим гарантируется что каждому пользователю будет возвращено уникальное значение генератора.
При выборке значения генератора запросом вида select gen_id(genname, x) from ... следует учитывать буферизацию выборки на клиенте. Т.е. в многопользовательской среде при выполнении двух таких запросов значения генератора будут увеличиваться "пачками", а не на величину x для каждой выбираемой записи.
Использование генераторов в триггерах и хранимых процедурах
Пример триггера, автоматически присваивающего уникальное значение ключевому полю таблицы:
создадим генератор для уникальной идентификации клиентов:
CREATE GENERATOR NEWCLIENT;
создадим триггер для таблицы CLIENTS:
CREATE TRIGGER TBI_CLIENTS FOR CLIENTS
ACTIVE BEFORE INSERT POSITION 0
BEGIN
В результате при создании новой записи полю CLIENT_ID будет автоматически присваиваться новое значение.
Однако при использовании генератора в триггере возникает проблема на клиентской стороне (например в BDE, используемом в Delphi, C++Builder ...), когда клиентское приложение пытается перечитать только-что вставленную запись. Поскольку триггер меняет значение первичного ключа вставляемой записи, BDE "теряет" такую запись и чаще всего выдает сообщение "Record/Key deleted". Поскольку SQL-сервер не может сообщить клиентскому приложению о новом значении ключевого поля, необходимо сначала запросить уникальное значение с сервера, и только затем использовать его во вставляемой записи. Сделать это можно при помощи хранимой процедуры
CREATE PROCEDURE GETNEWCLIENT
RETURNS (NID INTEGER )
BEGIN
NID = GEN_ID(NEWCLIENT, 1 ) ;
В Delphi, вы можете поместить компонент TStoredProc на форму, подсоединить его к данной процедуре, и например в методе таблицы BeforePost написать следующее
begin
begin
StoredProc1.ExecProc ;
StoredProc1.Params [ 0 ] .asInteger ;
end ;
end ;
После этого вышеприведенный триггер TBI_CLIENTS можно либо удалить, либо переписать так, чтобы генератор использовался только когда поле первичного ключа случайно приобрело значение NULL (например когда к таблице CLIENTS доступ осуществляется не через ваше приложение):
ALTER TRIGGER TBI_CLIENTS
BEGIN
IF (NEW .CLIENT_ID IS NULL) THEN
NEW .CLIENT_ID = GEN_ID(NEWCLIENT, 1 ) ;
Однако использование хранимой процедуры не всегда удобно - BDE может решить, что процедура вероятно изменяет какие-то данные на сервере, и в режиме autocommit завершит текущую транзакцию, что вызовет перечитывание данных TTable и TQuery. Более простым способом является получение значения генератора при помощи запроса:
SELECT GEN_ID(NEWCLIENT, 1) FROM RDB$DATABASE
При этом, если запрос помещен например в Query2, текст в BeforePost будет следующим:
begin
if DataSource.State = dsInsert then
begin
Query2.Open ;
ClientTable.FieldByName ("CLIENT_ID" ) .asInteger :=
Query2.Fields [ 0 ] .asInteger ;
Query2.Close ;
end ;
end ;
Такой способ более предпочтителен, чем использование хранимой процедуры для получения значения генератора, особенно при большом количестве генераторов.
Изменение значения генератора
Значение генератора можно переустановить при помощи оператора DDL
SET GENERATOR generatorname TO value;
Однако вы не сможете использовать такое выражение в теле триггера или хранимой процедуры, т.к. там можно использовать только операторы DML (а не DDL).
Если вы хотите обнулить генератор, или присвоить ему определенное значение в теле хранимой процедуры, то вы можете это сделать используя функцию GEN_ID:
(В данном примере генератор NEWCLIENT увеличивается на свое-же значение с отрицательным знаком.)
...
TEMPVAR = GEN_ID(NEWCLIENT, -GEN_ID(NEWCLIENT, 0);
...
Будьте внимательны при выполнении таких операций в многопользовательских средах. Приложения, процедуры и триггеры, которые в данный момент используют этот генератор, могут предполагать что он не будет "обнулен". Обязательно проверяйте "обнуление" генератора на возникновение конфликтных ситуаций при работе 2-х и более пользователей.
Получение текущего значения генераторов
Текущее значение генератора можно получить, вызвав функцию GEN_ID с нулевым увеличением значения генератора. Это можно сделать не только в триггере или хранимой процедуре, но и оператором SELECT
SELECT GEN_ID(NEWCLIENT, 0 ) FROM RDB$DA TABASE
Результатом выполнения запроса будет одна запись с одним полем, содержащим текущее значение генератора. Таблица RDB$DATABASES выбрана как содержаща в большинстве случаев одну запись, хотя использовать можно и любую другую таблицу.
При работе в многопользовательских средах будьте внимательны - в то время как вы получили "текущее" значение генератора, другое приложение может его изменить, и таким образом "текущее" значение окажется устаревшим. Тем более не рекомендуется использовать "текущее" значение генератора для его последующего изменения.
Удаление генераторов
В языке DDL Borland Interbase нет оператора для удаления генератора. Неизвестно, чем это вызвано, но серьезной проблемы не представляет. В самом начале статьи было упомянуто, что запись о генераторе создается в таблице RDB$GENERATORS. Эту запись, безусловно, можно удалить. Однако место, распределенное на странице генераторов, освобождено не будет. Оно будет освобождено только после того, как вы сделаете вашей БД BACKUP/RESTORE.
Нестандартное применение генераторов
Вы уже видели, что функцию GEN_ID можно использовать в операторе SELECT.
Вот как можно получить количество записей, выбранных запросом:
SET GENERATOR MYGEN TO 0 ;
SELECT GEN_ID(MYGEN, 1 ) , FIELD1, FIELD2, FIELD3, ... FROM MYTABLE.
Такой запрос вернет в качестве первого поля порядковый номер записи, и после выполнения запроса генератор MYGEN будет содержать количество возвращенных записей. Кроме этого, во время выполнения этого запроса любой другой пользователь этой-же БД может получить текущее значение генератора MYGEN и узнать сколько записей уже выбрано запросом на текущий момент (нечто вроде ProgressBar, однако число записей все-равно неизвестно до окончания выполнения запроса).
Функцию GEN_ID можно также использовать и как "выключатель" длительных запросов. Пример приведен для БД EMPLOYEE.GDB.
Фактически такой запрос означает - "выбирать записи пока значение генератора = 0". Как только другой пользователь или ваше приложение в другом коннекте выполнит операцию
SET GENERATOR EMP_NO_GEN TO 1 ;
запрос прекратится, т.к. условие WHERE станет равным FALSE.
(то-же самое, и даже в более сложных вариантах, можно делать при помощи UDF в Borland InterBase 4.2. см "Особенности версии 4.2")
примечание: обязательно учтитывайте буферизацию записей клиентской частью (gds32.dll) или сервером при выполнении подобных запросов. Например, приведенный выше запрос с проверкой генератора в where "выключится" не сразу, а через некоторое время.
Безусловно, в многопользовательской среде невозможно использовать в таких целях один и тот-же генератор. Для решения этой проблемы можно завести глобальный генератор, который будет выдавать уникальные идентификаторы пользователям при коннекте, а клиентское приложение будет запоминать его номер и хранить на локальном компьютере для последующего использования. Логика работы может быть следующая:
Клиентское приложение при запуске определяет, есть-ли для него (например в Registry или INI-файле) "именной" генератор.
Если нет, то оно операцией SELECT GEN_ID(GlobalGen, 1) FROM RDB$DATABASE получает идентификатор (например 150), создает на сервере собственный генератор операцией CREATE GENERATOR USER_N; (например USER150). После чего сохраняет имя этого генератора на локальном диске.
Если да, то приложение обнуляет "именной" генератор операцией SET GENERATOR ... TO 0; (в нашем примере SET GENERATOR USER150 TO 0;), и выдает запросы с использованием данного генератора.
История создания генератора .
В 1833 году русский ученный Э.Х.Ленц выдвинул теорию об обратимости эклектических машин. Он предположил, что если на одну и туже машину подать электричество, то она станет работать как электродвигатель, а если ее роутер с помощью другой машины привести в движение,то получиться генератор эклектического тока. А в 1987 году, бывшим членом комиссии испытывающей действие эклектического мотора Якоби доказал теорию обратимости эклектической машины.
Братья Пиксин, работающие техниками в Париже, основываясь на знаниях о явлении электромагнитной индукции, создали первый генератор электрического тока. Работа этого генератора основывалась на вращении тяжелого постоянного магнита, с помощью которого возникал переменный ток в двух неподвижно укрепленных вблизи полюсов проволочных катушек. Пользоваться этим генератором было крайне неудобно. В генератор было установлено устройство по выпрямлению тока. В дальнейшем для повышения мощности электрической машины братья увеличили число катушек и магнитов. В результате данного изобретения была в 1843 году построена машина , получившая название генератор Эмиля Штерера. Особенностью данной машины были шесть катушек, которые вращались вокруг вертикальной оси и три стальных подвижных магнита. До 1851 на первом этапе развития электрогенераторов магнитное поле получали при использовании постоянных магнитов.
Вторым этапом 1851-1867 гг. было создание генераторов, используемых электромагниты вместо постоянных магнитов. Что позволило увеличить мощность электрической машины.
Подобная машина была создана англичанином Генри Уальдом в 1863 г. В ходе эксплуатации данного вида генератора выяснилась уникальная возможность. Генераторы, вырабатывая электричество для потребителя, могли одновременно снабжать током и свои электромагниты. Как выяснилось, это возможно благодаря остаточному магнетизму, сохраняющемуся в сердечнике электромагнита даже после выключения тока. А значит, генератор с самовозбуждением может давать ток при запуске из состояния покоя. Основываясь на данном открытии, в 1866-1867гг изобретатели в разных уголках мира получили патенты на самовозбуждающиеся генераторы.
В 1870 году бельгийцем Зеноб Граммом был создан генератор, использовавший принцип самовозбуждения, а также был усовершенствован якорь, изобретенный Пачинотти в 1860 году. Данный генератор получил применение во многих областях промышленности.
В 1873 году на Венской международной выставке была произведена следующая демонстрация. Две одинаковые машины были соединены между собой километровыми проводами. Первая машина, служившая генератором электроэнергии , приводилась двигателем внутреннего сгорания в движение. Вторая являлась источником питания для насоса, получив по проводам электричество от первой. Это стало наглядной демонстрацией открытой Ленцем обратимости эклектических машин и легло в основу передачи энергии на расстояние.
Электрическая индукция или эффект трибоэлектрический, основанный на возникновении заряда, возникающий в следствии механического контакта двух диэлектриков, являются механизмом для выработки заряда.
Электрические генераторы, имеющие низкую мощность, имели низкую эффективность и проблемы с изоляцией так и никогда не получили масштабного использования в промышленности. Дожившие до нашего времени эклектические машины - это электрофорная машина, а также генератор Ваан де Графа.
Часто в состав первичного или уникального ключа входят цифровые поля, значения которых должны быть уникальны, то есть не повторяться ни в какой другой записи таблицы. В одних случаях такое значение является семантически значимым и формируется пользователем по определенному алгоритму -например, номер лицевого счета в банке. В других случаях лучше предоставить выработку такого значения приложению или серверу БД.
Для локальных СУБД (например, Paradox) для названной цели применяются автоинкрементные поля. При добавлении новой записи BDE автоматически устанавливает значение автоинкрементного поля так, чтобы оно было уникальным и не совпадало со значением данного автоинкрементного поля в других записях таблицы - не только существующих, но и удаленных. Иными словами, ранее использовавшееся значение автоинкрементного поля, даже если оно освободилось в результате удаления записи, никогда не назначается вновь. Изменить значение автоинкрементного поля нельзя.
В InterBase отсутствует аппарат автоинкрементных столбцов. Вместо этого для установки уникальных значений столбцов можно использовать аппарат генераторов.
Генератором называется хранимый на сервере БД механизм, возвращающий уникальные значения, никогда не совпадающие со значениями, выданными данным генератором в прошлом. Для создания генератора используется оператор
CREATE GENERATORИмяГенератора;
Для генератора необходимо установить стартовое значение при помощи оператора
SETGENERATOR ИмяГенератора ТО СтартовоеЗначение;
При этом СтартовоеЗначение должно быть целочисленным. Для получения уникального значения к генератору можно обратиться с помощью функции
GEN_ID(ИмяГенератора, шаг);
Эта функция возвращает увеличенное на шаг предыдущее значение, выданное генератором (или увеличенное на шаг стартовое значение, если ранее обращений к генератору не было).
ЗАМЕЧАНИЕ. Не рекомендуется переустанавливать стартовое значение генератора или менять шаг при разных обращениях к GEN_ID. В противном случае генератор может выдать неуникальное значение и, как следствие, будет возбуждено исключение "Дублирование первичного или уникального ключа" при попытке запоминания новой записи в ТБД.
Пример: Пусть в БД определен генератор, возвращающий уникальное значение для столбца N_RASH в таблице RASHOD
CREATE GENERATOR RASHOD_N_RASH;
SET GENERATOR RASHOD_N_RASH TO 20;
Обращение к генератору непосредственно из оператора
INSERT INTO RASHOD (N_RASH, DAT_RASH, KOLVO, TOVAR, POKUP) VALUES (GEN_ID (RASHOD_N_RASH, 1) ,"10-JAN-1997",100, "Сахар", "Лира, TOO") .
Присваивание ключевому столбцу уникального значения может быть реализовано через триггер, вызываемый перед запоминанием новой записи БД:
CREATE TRIGGER BI_RASHOD FOR RASHOD
NEW .N_RASH = GEN_ID (RASHOD_N_RASH, 1);
При этом в клиентском приложении, реализующем добавление новых записей в таблицу, столбец с уникальными значениями (в нашем случае N_RASH) в программе не заполняется и оператор INSERT имеет вид
INSERT INTO RASHOD (DAT_RASH, KOLVO, TOVAR, POKUP)
VALUES (: DAT_RASH, : KOLVO, : TOVAR, : POKUP)
Как можно заметить, столбец N_RASH в операторе не упоминается: все необходимые действия по заполнению этого столбца уникальным значением выполняет триггер BI_RASHOD.
"Обмануть" BDE можно, присваивая столбцу N_RASH любое значение, которое затем будет заменяться триггером на значение, полученное при помощи функции GEN_ID. Однако более корректным будет в данном случае использование не триггера, а процедуры:
CREATE PROCEDURE GET_N_RASH
RETURNS (NR INTEGER)
Большинство SQL-серверов имеет специальные механизмы для создания уникальных идентификаторов - autoincrement, identity, sequence, и т. п. В InterBase и Firebird для этого существует механизм генераторов.В данной статье будут рассмотрены следующие темы:
Нужно сразу заметить, что сами по себе генераторы не обеспечивают сохранение последовательности номеров в случае удаления записей - генератор всего лишь выдает числа по очереди увеличивая их на некоторую величину и обеспечивая уникальность выданных значений. То есть, генератор выглядит как переменная типа integer (в первом диалекте, или int64 в третьем диалекте), которая находится в памяти, и над которой можно выполнять операции Inc и Dec. Если вам требуется обеспечить непрерывные последовательности идентификаторов записей даже в случае их удаления или модификации, то вам нужно обратиться к статье Auditable series of numbers (непрерывные последовательности чисел). В любом случае это задача приложения и сервера, и выходит за рамки данного описания.
CREATE GENERATOR generatorname;
При выполнении такой команды происходит 2 действия:
GEN_ID(generatorname, inc_value)
Где inc_value
- число, на которое необходимо прирастить значение генератора.
Внимание!
Получить новое значение генератора можно
1. оператором select, выбрав значение gen_id из таблицы с одной записью, например, системной rdb$database:
select gen_id(my_gen, 1) from rdb$database
2. в триггерах и процедурах - просто присвоив значение gen_id переменной:
myvar=gen_id(my_gen, 1);
3. в запросах - просто вызовом функции gen_id(my_gen, 1)
Генераторы возвращают значения (и сохраняют свои значения на диске) вне контекста транзакции пользователя. Это означает, что если значение генератора было увеличено с 10 до 11 (инкремент 1), то даже при откате транзакции (ROLLBACK) значение генератора, выданное в этой транзакции, не вернется к предыдущему. Вместе с этим гарантируется, что каждому пользователю будет всегда возвращено уникальное значение генератора (вызов функции gen_id всегда происходит "монопольно", то есть непараллельно для любого числа одновременных вызовов, чтобы исключить возможность получения разными пользователями одного и того же значения).
Примечание. Приращение значения генератора производится монопольно, аналогично функции InterlockedIncrement в Win32 API. То есть, даже если 1000 пользователей одновременно вызовут gen_id(x, 1), то они получат каждый свое (уникальное) значение (от x+1 до x+1+1000).
При выборке значения генератора запросом вида select gen_id(genname, x) from ... следует учитывать буферизацию выборки на клиенте. Т.е. в многопользовательской среде при выполнении двух таких запросов значения генератора будут увеличиваться "пачками", а не на величину x для каждой выбираемой записи.
Примечание.
Иногда находятся умельцы, которые пишут
select gen_id(a, 0) + 1 from rdb$database
или
tmp=gen_id(a, 0);
tmp=tmp+1;
и др. аналогичные варианты. Если непонятно, почему так делать нельзя, прочитайте примечание выше еще раз.
CREATE GENERATOR NEWID;
SET GENERATOR NEWID 1000;
Обычно "начальное" значение генератора устанавливают в отличное от нуля, когда база данных является "распределенной", то есть в разных филиалах могут создавать новые записи в какой-либо таблице. Например, в главном офисе нумерация начинается с 0, в первом филиале - с 100000, во втором - с 200000, и так далее. Такой подход позволит избежать ситуаций, когда в двух филиалах созданы разные записи с одинаковым идентификатором.
Другой случай - наличие готового справочника с фиксированными идентификаторами. В этом случае вам нужно установить значение генератора больше максимального существующего идентификатора такого справочника.
В общем, установка начального значения генератора <> 0 зависит только от специфических требований приложения.
GEN_ID(NEWID, 1);
Увеличение значения генератора функцией GEN_ID производится в монопольном режиме. Это означает, что одновременный вызов GEN_ID(NEWID, 1) двумя приложениями вернет каждому только свой идентификатор. Пример:
генератор имеет значение 7
приложение1: gen_id(newid, 1) -- выдан номер 8
приложение2: gen_id(newid, 1) -- выдан номер 9
...
SELECT GEN_ID(NEWID, 1) FROM RDB$DATABASE
Такой же способ используется в компонентах IBX LINK и FIBPlus - у IBDataSet есть метод GeneratorField, который позволяет обеспечить автоматическое присвоение нового номера столбцу первичного ключа записи как раз при помощи указанного оператора select, выполняемого библиотекой компонент "прозрачно". В FIBPlus та же самая функциональность устанавливается при помощи FIBDataSet.AutoUpdateOptions (GeneratorName).
Если вы по каким то причинам не хотите или не можете пользоваться методом GeneratorName, то можно взять отдельный компонент IBSQL (или IBQuery), прописать в нем запрос получения нового значения генератора, и вызывать такой запрос перед вставкой новой записи в таблицу.
CREATE TRIGGER TBI_CLIENTS FOR CLIENTS
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
То есть, новый идентификатор присваивается автоматически при вставке записи. Такой способ вполне нормален, однако он подходит только для случаев, когда приложение вставляет запись и дальше уже не интересуется ею. Дело в том, что при многопользовательской работе и данном способе невозможно узнать, какое именно значение генератора было присвоено столбцу при вставке. Следовательно, если вам (или используемым компонентам доступа) нужно знать созданный идентификатор, то следует воспользоваться методом, изложенном выше в разделе SELECT.
Конечно, триггер можно оставить, изменив лишь код
IF (NEW.CLIENT_ID IS NULL) THEN
NEW.CLIENT_ID = GEN_ID(NEWID, 1);
Чтобы если никакое значение столбца CLIENT_ID при вставке записи из приложения не передано, то оно было сгенерировано автоматически.
Примечание. Первая попытка перенести ответственность за автоматическую нумерацию столбца первичного ключа таблицы обычно проваливается из-за компонент доступа. Поскольку такой столбец объявлен как not null, и компоненты автоматически считывают характеристики столбцов, у TField будет установлено в True свойство Required. Это не дает возможности оставить столбец "пустым" при передаче с клиента на сервер. Установите свойство Required у такого столбца в False.
Примечание. Данная проблема может быть решена в Firebird 2.0, при помощи оператора INSERT...RETURNING. Однако если вручную (через IBSQL, IBQuery) такой оператор можно выполнить и получить из него результат, то для IBDataSet это может оказаться невозможным, поскольку IBDataSet или IBQuery+IBUpdateSQL просто не будут знать, что оператор вставки что-то возвращает. Если от FIBPlus можно ожидать поддержки insert...returning после выхода Firebird 2.0, то от IBX - вряд ли, если только аналогичная функциональность будет реализована в InterBase.
CREATE PROCEDURE GETNEWCLIENT
RETURNS (NID INTEGER)
AS
BEGIN
NID = GEN_ID(NEWCLIENT, 1);
SUSPEND;
SELECT NID FROM GETNEWCLIENT
EXECUTE PROCEDURE GETNEWCLIENT RETURNING_VALUES:param
CREATE PROCEDURE GETNEWID
(GENID INTEGER)
RETURNS (NID INTEGER)
AS
BEGIN
IF (:GENID = 1) THEN
NID = GEN_ID(NEWCLIENT, 1);
IF (:GENID = 2) THEN
NID = GEN_ID(NEWORDER, 1);
IF (:GENID = 3) THEN
NID = GEN_ID(NEWSALE, 1);
CREATE PROCEDURE GETNEWID
(GEN VARCHAR(30))
RETURNS (NID BIGINT)
AS
DECLARE VARIABLE SQL VARCHAR(60);
BEGIN
SQL = "SELECT GEN_ID("||GEN||", 1) FROM RDB$DATABASE;
EXECUTE STATEMENT SQL INTO:NID;
SUSPEND
END
Обратите внимание, что возвращаемая переменная NID имеет тип BIGINT, в отличие от предыдущих примеров - execute statement требует точного соответствия типов переменных. Если требуется получить результат в тип integer, то следует применить операцию cast(var as integer) либо сразу в запросе, либо к выходной переменной после того, как значение получено из execute statement.
Следует помнить, что execute statement производит динамическое выполнение запроса, а значит это будет чуть медленнее, чем выполнение такого запроса с клиента. Пример вызова процедуры (suspend в процедуре опять же указан для возможности ее вызова как select):
SELECT * FROM GETNEWID("NEWCLIENT");
SELECT * FROM GETNEWID("NEWORDER");
SELECT * FROM GETNEWID("NEWSALE");
SELECT GEN_ID(NEWCLIENT, 1) FROM RDB$DATABASE;
SELECT GEN_ID(NEWORDER, 1) FROM RDB$DATABASE;
...
то есть, сначала генератор будет инкрементироваться приложением, а потом еще и триггером. Поэтому, проверьте, содержит ли данный триггер проверку столбца на is null, как это указано ранее в статье.
Это может быть связано с тем, что генератор удален и создан снова. При этом в коде blr процедуры или триггера, которая явно ссылается на имя генератора, осталась ссылка на старый идентификатор генератора, в то время как в rdb$generators этот генератор уже имеет новый идентификатор.
Для решения этой проблемы нужно сделать alter trigger/procedure, чтобы перекомпилировался blr.
Примечание. Данная проблема вовсю существовала во времена повсеместного использования SQLExplorer (инструмента BDE). Он при попытке изменить значение генератора почему то удалял и создавал генератор снова.
Такие операции чаще выполняют как установку значений генераторов в некие начальные, при установке системы на новый сервер (филиал, подразделение, однопользовательское рабочее место и т. п.). Следует категорически избегать таких действий во время работы в многопользовательской среде, т. к. это нарушит нормальную работу приложений (генератор может начать выдавать значения, уже существующие в таблицах).
SET GENERATOR NEWCLIENT TO 0;
...
TEMPVAR = GEN_ID(NEWCLIENT, -GEN_ID(NEWCLIENT, 0));
...
То есть, генератор увеличивается на его же текущее отрицательное значение.
SELECT GEN_ID(NEWCLIENT, 0) FROM RDB$DATABASE
Если backup/restore метаданных используется для создания "клона" базы данных, используемого в другой фирме, офисе и т. п., то вам придется самостоятельно или обнулить генераторы, или установить их в требуемые значения.
В результате, после рестарта сервера, в базе могут оказаться "старые" значения генераторов, при том что данные уже содержат идентификаторы, полученные от "новых" значений.
Это исправлено в Firebird 1.5.2, то есть страницы генераторов записываются на диск до записи страниц с данными. На других версиях InterBase/Firebird/Yaffil с данной проблемой можно бороться только написав специальную программу "восстановления" или контроля значений генераторов после сбоя, которая будет содержать проверку на select max(id) from table и установку соответствующего генератора в это значение.
declare variable i int;
begin
SELECT GEN_ID(X, 1) FROM RDB$DATABASE
INTO:I;
...
declare variable i int;
begin
I = GEN_ID(X, 1);
INSERT INTO TBL VALUES (:I...
...
begin
INSERT INTO TBL VALUES (GEN_ID(X, 1), ...
...
Встречаются случаи избыточного преклонения перед примером с rdb$database:
values (select gen_id(mygen, 1)from rdb$database, :param...)
insert into table (field1, field2...)
values (gen_id(mygen, 1), :param...)
Более существенная и грубая ошибка в использовании генераторов - это увеличение "текущего" значения генератора вне контекста gen_id. Схематично выглядит как
I = GEN_ID(X, 0);
I = I + 1;
Или еще более безумный вариант
SELECT GEN_ID(X, 0) + 1 FROM RDB$DATABASE
Как интересный пример самостоятельного использования mutex при необходимости обеспечения сложной последовательности увеличения значений, можете посмотреть udfdemox . Используемая в нем функция mutex упоминается дальше по тексту статьи.
SET GENERATOR MYGEN TO 0;
SELECT GEN_ID(MYGEN, 1), FIELD1, FIELD2, FIELD3, ... FROM MYTABLE.
Понятно, что такой способ невозможно использовать для нескольких приложений одновременно, т. к. в этом случае значения генератора будут увеличиваться скачками.
Функцию GEN_ID можно также использовать и как "выключатель" длительных запросов. Пример приведен для БД EMPLOYEE.GDB.
Фактически такой запрос означает - "выбирать записи пока значение генератора = 0". Как только другой пользователь или ваше приложение в другом коннекте выполнит операцию
SET GENERATOR EMP_NO_GEN TO 1;
Запрос прекратится, т. к. условие WHERE станет равным FALSE.
Обязательно учтитывайте буферизацию записей клиентской частью (gds32.dll) или сервером при выполнении подобных запросов. Например, приведенный выше запрос с проверкой генератора в where "выключится" не сразу, а через некоторое время. Перед применением такого метода в вашей системе сначала следует проверить, подходит ли он вообще для выполняемого вами запроса.
Безусловно, в многопользовательской среде невозможно использовать в таких целях один и тот же генератор. Для решения этой проблемы можно завести глобальный генератор, который будет выдавать уникальные идентификаторы пользователям при коннекте, а клиентское приложение будет запоминать его номер и хранить на локальном компьютере для последующего использования. Логика работы может быть следующая:
При помощи генераторов можно также решить проблему с отсутствием временных таблиц в вашей версии сервера (временные таблицы появились в InterBase 7.5LINK). Вы создаете таблицу, например TEMP_TBL, и в качестве первого поля, входящего в первичный ключ, указываете поле типа INTEGER. Пользователь при соединении с сервером получает собственный идентификатор у некоторого общего генератора, и затем использует его при помещении записей в такую "временную" таблицу. В результате, даже если несколько пользователей будут работать с такой таблицей, они никогда не "пересекутся" по значению первого поля первичного ключа "временной" таблицы..
Если вам нужно, чтобы некая процедура выполнялась монопольно, то есть всегда в одном экземпляре (какой-нибудь сложный расчет), то для этого можно использовать генератор следующим образом:
create procedure GENREPORT
as
declare variable i int;
begin
i = GEN_ID(REPGEN, 1); -- проверим, запущена ли процедура
if (i > 1) then -- да, процедура уже работает
begin
i = GEN_ID(REPGEN, -1); -- возвращаем значение обратно
EXCEPTION REPORT_ALREADY_RUNNING;
Обработка отчета
i = GEN_ID(REPGEN, -1); -- отчет закончен, возвращаем значение обратно
Здесь есть скрытая проблема. Если вдруг в момент обработки произойдет ошибка, то без обработки исключений последняя строка в процедуре, возвращающая значение генератора обратно, не выполнится. И в результате второй раз завершившуюся с ошибкой процедуру запустить не удастся. Есть два варианта решения этой проблемы:
select gen_id(repgen, -1) from rdb$database с клиента в случае неуспешного выполнения процедуры.
Если вам не нравится использовать генератор для данных целей, то вы можете точно так же использовать функции WaitForAccess и ReleaseAccess из udfdemox . Обработку ошибок при использовании mutex нужно планировать так же, как и для генераторов.