Использую D7 + FibPlus 6.9.9 + Firebird 2.1. База в локальном режиме, 1 юзер, хотя потом планируется многопользовательская работа.

В общем, впервые для себя обнаружил ошибку вот такого вида:



Не подозревал, что даже в локальном режиме могут быть проблемы с первичным ключом, точнее с генератором. Поясню подробнее: есть таблица-справочник номенклатуры, в которой на данный момент 211 записей. При добавлении новой записи (точнее при Post) возникает вышеобозначенная ошибка. Посмотрел текущее значение генератора в IB Experte и был удивлен - значение 39, когда явно должно быть 211. Скрипт генератора-триггера для таблицы классический: 



Настройки фибдатасета тоже обычные в принципе:



Вопрос - каким образом и что могло повлиять на значение генератора, которое по логике должно быть максимальным  ?

Добавлено @ 23:43
что еще хотел добавить по теме, что никаких процедур и вообще чего либо, меняющего значение генератора данной таблицы не используется вообще, кроме того что описал.

Это сообщение отредактировал(а) Cinemaizer[Олег] - 21.1.2011, 01:18

триггер будет пользоватся генератором для Id толлько если при добавлении вы передали NULL для поля Id. А можно увидеть запросы добавления-обновления?

Что характерно, читая статью про генераторы:
http://ibase.ru/devinfo/generator.htm


нашел следующее:


В итоге выходит, что у меня как раз та самая "другая версия" Firebird   и надо внедрять select max(id) ?

Добавлено @ 01:09


ок, что было сгенерировано автоматическим способом в настройках фибдатасета. в моем коде ничего в рантайме не меняю:


INSERT INTO NOMENKLATURA(
    ID,
    NTYPE_ID,
    NGROUP_ID,
    NAME,
    NAME_FOR_PRINT,
    UID,
    UNITS_ID,
    DEFAULT_NUMBER,
    MIN_REST,
    RETAIL_PRICE,
    MARKUP,
    ARTIKUL,
    POT_PROFIT_CATEGORY,
    PURCH_PRICE,
    VENDOR,
    ADDINPRICELIST,
    PRIZN_NOMENKL_ID,
    NOTES,
    PHOTO,
    DELETED,
    DEL_BY,
    DEL_DATE,
    DEL_TIME
)
VALUES(
    :ID,
    :NTYPE_ID,
    :NGROUP_ID,
    :NAME,
    :NAME_FOR_PRINT,
    :UID,
    :UNITS_ID,
    :DEFAULT_NUMBER,
    :MIN_REST,
    :RETAIL_PRICE,
    :MARKUP,
    :ARTIKUL,
    :POT_PROFIT_CATEGORY,
    :PURCH_PRICE,
    :VENDOR,
    :ADDINPRICELIST,
    :PRIZN_NOMENKL_ID,
    :NOTES,
    :PHOTO,
    :DELETED,
    :DEL_BY,
    :DEL_DATE,
    :DEL_TIME
)



UPDATE NOMENKLATURA
SET 
    NTYPE_ID = :NTYPE_ID,
    NGROUP_ID = :NGROUP_ID,
    NAME = :NAME,
    NAME_FOR_PRINT = :NAME_FOR_PRINT,
    UID = :UID,
    UNITS_ID = :UNITS_ID,
    DEFAULT_NUMBER = :DEFAULT_NUMBER,
    MIN_REST = :MIN_REST,
    RETAIL_PRICE = :RETAIL_PRICE,
    MARKUP = :MARKUP,
    ARTIKUL = :ARTIKUL,
    POT_PROFIT_CATEGORY = :POT_PROFIT_CATEGORY,
    PURCH_PRICE = :PURCH_PRICE,
    VENDOR = :VENDOR,
    ADDINPRICELIST = :ADDINPRICELIST,
    PRIZN_NOMENKL_ID = :PRIZN_NOMENKL_ID,
    NOTES = :NOTES,
    PHOTO = :PHOTO,
    DELETED = :DELETED,
    DEL_BY = :DEL_BY,
    DEL_DATE = :DEL_DATE,
    DEL_TIME = :DEL_TIME
WHERE
    ID = :OLD_ID
    


Это сообщение отредактировал(а) Cinemaizer[Олег] - 21.1.2011, 01:13

У меня стоит  Firebird 2.1.3 FIB 6.9.6 за год подобного ниразу не было, правда embedded редко использовался.

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

Правда у меня в основном на процедурах и триггерах работа с  идентификаторами, а там где надо программно получить ID использую не wgBeforePost а wgOnNewRecord для гарантии так сказать)) мне ведь по сути не важно какое там число будет записано, лиш бы гарантироано уникальное. Пусть уж лучше пару тройку значений пропустит при возможных сбоях, или отказах от сохранения.

Это сообщение отредактировал(а) vovk - 21.1.2011, 01:26

нет.
Написано же: "Это исправлено в Firebird 1.5.2", имеется ввиду в версии >= 1.5.2.
Как думаешь, твоя версия (2.1) вышла раньше чем 1.5.2?
Вопрос: как они туда попали? Через твою программу или импортировались из стороннего справочника?
Может значение генератора кто-то принудительно установил?

Это была шутка юмора такая  

Добавлено @ 07:32

Попали через мою программу.

Исключено


Это сообщение отредактировал(а) Cinemaizer[Олег] - 21.1.2011, 07:34

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

  
А поподробнее?
и сервер не падал?

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

а чего ему падать то? локалка, 1 юзер.

Добавлено через 9 минут и 31 секунду

Кстати да, можно подетальнее про это дело???


Это сообщение отредактировал(а) Cinemaizer[Олег] - 21.1.2011, 08:44

у TpFIBDatabase еслт опция ddoStoreConnected она может напакастить... была проблема с диалектом в дизайне одно при запуске другой, оказалось что FIB сохранил в реестре не правильную настройку диалекта...

не факт что эта опция может повлеять но TpFIBDataSet но все же....

Это сообщение отредактировал(а) Frees - 21.1.2011, 08:59

Frees, что-то странное ты про диалекты рассказываешь.
Если БД была создана в 1-м, то что ни ставь в дизайн, в ран будет всегда 1
Если БД была создана в 3-ем, то подключиться к ней с 1 тоже проблема.

Точно, Frees был прав. Поскольку дело было глубоким ночером, то вследствие копипастинга или усталости не углядел, как "чужие" датасеты втихую генерят мой номенклатурный генератор.   
В общем, тема закрыта. Всем спасибиссимо за участие!!!

Дело было так, БД была создана в 3 диалекте в дизайне стоял 3 диалект, а после запуска в отладке показывал диалект 1...дело оказалось в опции ddoStoreConnected...

Это сообщение отредактировал(а) Frees - 21.1.2011, 15:01