Имеется в виду следующая ситуация:

Есть документ, с подчиненным списком. Для примера, предположим что это список дат очередных платежей. Например:

01.01.2003
02.01.2003

В базе данных я сделал триггер на проверку уникальности даты в пределах одного документа (недопустимо в одном документе иметь 2 одинаковые даты). Проверка необходима именно на уровне триггеров, поскольку есть возможность правки документа нескольким пользователями одновременно.

Теперь пользователь изменил эти даты следующим образом:

02.01.2003
03.01.2003

Такое изменение никогда не будет принято, поскольку при проверке первого значения (02.01.2003) триггер обнаружит, что такое значение уже есть (это старое значение второй записи - до него еще не дошла очередь на изменение)

Есть ли возможность оставить контроль уникальности на уровне триггеров, но тем не менее не напороться на эти грабли?

Если одновременно несколько пользователей правят - то буферизация,
если буферизация, то триггеры вроде спят.
В качестве ликбеза - где я не понял ?

Триггеры срабатывают в момент записи информации из буфера непосредственно в таблицу. При одновременном редактировании нескольким пользователями есть вероятность и "одновременной" записи изменений.

Но в данном случае проблема возникает при сбросе изменений произведенных одним пользователем.

не-а, мне кажется триггер не триггер, а если таблица организована таким образом, что значения там уникальны (ну либо уникальны для одного клиента), то по всему такого типа замены недопустимы в принципе.... Компьютер ведь НЕ ЗНАЕТ, что ты сменишь дату у определенного диапазона записей, он мыслит ЗДЕСЬ И СЕЙЧАС.... Тут как-то по-другому крутиться надо, типа забирать редактируемые записи в курсор без жесткого соблюдения уникальности, править там, а потом заменять записи в собственно таблице, причем именно сверху вниз по датам.... Короче, все равно криво достаточно....

А индекс по bintoc(parentid,4) + dtos(date) чем не удовлетворяет?

Ведь проверка уникальности индекса будет осуществляется при tableupdate-е, а это как раз то, что требуется.

2 Анатолий Широков

Потому что использование такого индекса абсолютно идентично использованию триггера. Будет та же ситуация.

PS: не надо снова разворачивать дискуссию - индекс типа Candidat или триггер - лично я использую триггер. Вопрос ведь совсем не о том.

По-моему они работают раньше триггеров. Если в них сделать так, чтобы сначала шла замена {02/01/2003} на {03/01/2003}, а потом {01/01/2033} на {02/01/2003}, то триггеры пропустят. Я дилетант в DBC, но в Free tables смог бы это организовать.
Спасибо.

Т.е. проверка в буфере на этапе ввода (непосредственно в форме), а на этапе записи (триггера, индексы) вообще отказаться от проверки на уникальность?

В этом случае, конечно снимаются конфликты для одного пользователя, но остается конфликт совместного редактирования

Да, триггеры срабатывают самыми последними, когда выполнились все прочие проверки. Однако Rule здесь в принципе не применимо.

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

Кстати, никто не проверял, сброс буфера при табличной буферизации происходит в порядке физического следования записей или по активному индексу?

Планируется юзать представление в буф5 или прямой 5-й буфер?