Update or Insert и FireBird 2.5.2

[Аватар]

И какова будет скорость Базы при частых таких запросах?

Скорость будет нормальная если индекс есть по тому полю (полям), по которому поиск

[Stilet]

Как поступать? Искать её на наличие, а по результату уже выполнять UPDATE или INSERT?

Я так и поступаю. Тормоза меня еще не посещали, хотя иногда приходится на удаленном компе выполнять 10000 таких запросов (всмысле селект один, а инсертов тысячи). Не жалуюсь.

[Yurk@]

то после второго вызова этой же операции произойдёт уже не INSERT, а UPDATE, что соответствует инструкции, но... будет обновлено значение первичного ключа из генератора на новое.

немного не так) ... нужно видеть текст тригера который генерит ft_id.

Зачем update or INSERT в таблицу, в которой значение ключа триггером генерируется? Эта конструкция для таблиц, в которых это значение программно создается и не более того

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

NEW.ft_id = GEN_ID(generator, 1);

то будет ошибка, а если в тригере текст

IF (NEW.ft_id IS NULL) THEN 
  NEW.ft_id = GEN_ID(generator, 1);

- то такая конструкция будет успешно обрабатываться с помощью UPDATE OR INSERT

[Pashka_cool]

вот мой триггер:
AS
begin
if (NEW.indexid is NULL)
then NEW.indexid = next value for gen_a_ftypes_id;
end
И при втором подряд "UPDATE or INSERT" выдаёт ошибку нарушения уникальности.
А вот пример двух команд подряд:
update or insert into a_ftypes(ftname, ftdescr, ft_id) values('DEFAULT', '', 12) matching(ft_id);
update or insert into a_ftypes(ftname, ftdescr, ft_id) values('DEFAULT', '', 22) matching(ft_id);

При этом обе должны выполнить INSERT, т.к. обоих записей ещё нет. Уникальное поле "ft_id". Но это не ключевое поле, а просто уникальное. Ключевое поле не упомянуто, его имя "indexid". Оно должно автоматически сгенерироваться триггером при INSERT-е. А при повторном выполнении будет уже UPDATE и это поле "indexid" просто и не меняется.
И вот эта задача не работает. Выдаёт ощибку:
Invalid insert or update value(s): object columns are constrained - no 2 table rows can have duplicate column values.
violation of PRIMARY or UNIQUE KEY constraint "PK_A_FTYPES" on table "A_FTYPES".
При этом поле "indexid" - ключевое.
Поле "ft_id"- просто уникальное, чисто идентифиактор целочисленный. Потому именно по "ft_id" идёт MATCHING в выражениях.
Вот и вся ситуация.

[Yurk@]

При этом обе должны выполнить INSERT, т.к. обоих записей ещё нет.

О_о
а на кой тогда генератор если ты вручную указываешь ft_id?
и еще, покажи что у тебя за индекс PK_A_FTYPES ? на какие он поля и какие настройки уникальности?

[Vapaamies]

Триггер на какое событие?

[Pashka_cool]

праймари ключ PK_A_FTYPES на поле INDEXID. Триггер берёт из генератора именно для него значение. А поле FT_ID задаёт пользователь, но оно тоже уникально. Это поле содержит некое справочное значение, на которое код реагирует, когда загружает данные из таблицы. Имеется ввиду код софта.

[Yurk@]

ну он у тебя и ругается на INDEXID.
если есть фозможность - выложи файлик с БД. где-то у тебя косяк закрался

[Аватар]

Надыбал интересное обсуждение похожей проблемы
http://www.sql.ru/forum/893230/inser...te-ne-rabotaet

[Pashka_cool]

АВАТАР, спасибо за статью. Очень похожая ситуация, действительно.
Либо данный операнд довольно хрупок в применении (и мне не удалось подобрать к нему "ключи"), либо он вообще недопилен в этой версии сервера. Не могу судить об этом однозначно. По крайней мере то, как я пытаюсь им пользоваться сугубо интуитивно и очевидно - не работает. Стоило бы обратиться к разработчикам Базы, т.к. в другом случае мы все подойдём к позиции "научного тыка" и большой потери времени. У меня проект через месяц должен быть запущен в первой версии, потому буду делать "медленное но верное" решение. Потом время покажет. Может быть и вправду даже при моей нагрузке тормазо меня не посетят (а точнее мой продукт и мою Базу).