Master-detail.
В триггере BeforeInsert master-таблицы выполняется проверка данных и, в случае ошибки, вызывается исключение. 
Изначально генерацию первичного ключа выполнял в триггере после всех проверок, однако потребовалось получать id добавленной записи для detale-таблицы и обновлять только измененную запись. Стал использовать AutoUpdateOptions компонента FIBDataSet master-таблицы. Но в этом случае генератор изменяется до проверки исключений в триггере. Получается, что если несколько раз возникало исключение, то номер записи будет больше на число исключений. 
Как избежать многократного изменения значения генератора, но при этом сохранить возможность получения ключа для detail-таблицы и обновления добавленной записи?
Active - false/true не предлагать.

Для FireBird 2.0 и больше



после Post  поле id добавленной записи будет заполнено значением заполненным в базе

former, вопрос еще актуален?

Deniz, если есть еще вариатны, с удовольствием их выслушаю.

former, я вообще не понимаю, зачем так делать, что вызов исключения влияет на срабатывание генератора?
Ты хоть бы код показал

Именно. В AutoUpdateOptions есть свойство WhenGetGenID, которое имеет wgNever (не используется), wgBeforePost (перед вызовом Post), wgOnNewRecord (при вызове Insert). 
У меня контроль данных осуществляется в триггерах с вызовом исключений. Получается следующее:
wgOnNewRecord
Вызываем Insert, генерируется значение ключа, вводим данные, вызываем Post, получаем исключение, а генератор уже изменен.
wgBeforePost
Вызываем Insert, вводим данные, вызываем Post (генерируется значение ключа), получаем исключение, а генератор уже изменен.
А для выполнения Refresh необходимо значение ключа добавленной записи.

ИХМО:А код тут не причем.

у компоненты базы данных (FibDataBase) есть метод получения кода генератора, его и используй. В этом случае триггер не будешь трогать.

Добавлено через 2 минуты и 33 секунды
Пример


Добавлено через 4 минуты и 15 секунд

а ты поставь код получения значения генератора после кода вызова исключения  
тогда в случае исключения код получения значения генератора не будет срабатывать 

В твоем коде, в случае возникновения исключения и повторного вызова метода Post, будет сгенерировано новое значение генератора. А если возникнет несколько исключений, то вместо 15-го мы запишем запись с ключем номер 25. Не очень хочется "транжирить" генератор.

Именно так я и делаю:

Akella, для Refresh тогда откуда возьмется ключ записи? 

Это сообщение отредактировал(а) former - 8.9.2009, 10:51

А при чём здесь генератор?

А вот причем:

Обрати внимание на последнюю строку.

Refresh выполняется после чего? После Update!
абчём говорит эта строка?


Добавлено через 1 минуту и 1 секунду
Если речь идёт об insert, то нужн что делать? Правильно - pFibDataSet1.CloseOpen();

Вот с этого все и начинается  
Попробуй посчитать сколько примерно сотен лет нужно чтобы занять весь генератор при условии что 1 запись вставляется каждую секунду в режиме 24х7.
Далее, не совсем понятно почему часть бизнес логики (по обработке 1 записи) вынесена в триггер, а часть остается на клиенте.
Далее, такие проверки как в триггере, можно оформить как not null на поле, а на клиенте преобразовывать пустые в null (есть вроде такая опция в FIBPlus)
Далее, удивил код с это реальные грабли, причем получишь ими, когда люди начнут работать толпой, лучше пользуй уникальные индексы.
И наконец, если мне не изменяет память, то после исключения на POST, DataSet остается в режиме редактирования, и повторно onNewRecord не вызывается, если только ты сам не делаешь Cancel.

Порядка 30 млн. записей в год. В некоторых случаях мне нужна четкая последовательность нумерации.

Где такое написано, что преобразование идет на клиенте? Клиент только передает данные.


Это если уникальность в одном поле. А когда уникальность по нескольким полям то как?
Какие грабли?

Да, именно если пользователь делает Cancel.

Это сообщение отредактировал(а) former - 8.9.2009, 14:04

В опциях стоит RefreshAfterPost:=true. Если установлено свойство WhenGetGenID в wgBeforePost или wgOnNewRecord, Id для обновления берется из него.
А если wgNever, то можно подсунуть Refresh-у номер записи и он ее обновит.

Если делать pFibDataSet1.CloseOpen(), то потом нужно будет искать добавленную запись. А так, сразу попадаем на нужную запись. Тем более весь набор данных заново открывать.

Это сообщение отредактировал(а) former - 8.9.2009, 14:22

это твой реальный прирост?

зачем? Поподробнее можно? Обычно id кроме разработчиков никто не видит.

а что уникальные составные ключи отменили? Из Firebird-2.0-LangRef:

Запрос работает в контексте транзакции, т.е. на момент запроса в базе уже может быть такая запись, в неподтвержденной транзакции, и твой запрос ее не увидит, а потом транзакция подтвердится и ты получишь 2 одинаковые записи.

Если уж так необходимо гарантировано соблюсти последовательность, то оформить insert into в хранимку с предварительной проверкой и последующей вставкой. Результат храминки или ID или код ошибки (например отрицательный).