Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Разные ошибки одного запроса [D7, FireBird 1.5]

Dik59 © (2006-10-16 20:24:00)
Доброго времени суток, Мастера.

При выполнении запроса на вставку данных с одними и теми же некорректными данными получаю два РАЗНЫХ сообщения:
при нечетных запусках (первый, третий, пятый раз и т.д.) имею сообщение:

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 "DMS_PK" on table "DMS".

что нормально, так и должно быть,
а при четных запусках получаю:

Too many concurrent executions of the same request

Что это? глюк FireBird или я чего-то не понимаю?

на всякий случай текст запроса, хотя он наверняка не нужен:

insert into dms (doc,def,def_,str)
select doc,def, -1,name from def where name is not null
and doc = 0 and def=-1

Германн (2006-10-18 02:46:00) [1]

> Dik59 (16.10.06 20:24)
>
> Доброго времени суток, Мастера.
>
> При выполнении запроса на вставку данных с одними и теми
> же некорректными данными получаю два РАЗНЫХ сообщения:
> при нечетных запусках (первый, третий, пятый раз и т.д.)
> имею сообщение:
>
> 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 "DMS_PK" on
> table "DMS".
>
> что нормально, так и должно быть,
> а при четных запусках получаю:
>
> Too many concurrent executions of the same request
>

По поводу "Too many concurrent executions of the same request", имхо, тебе следует обновить FB. Читай тут http://www.ibase.ru/firebird/fb_1_52_releasenotes.pdf

Dik59 (2006-10-18 02:22:00) [2]
Поясню:
попытка исполнения ОДНОГО и ТОГО ЖЕ запроса приводит к появлению РАЗНЫХ сообщений от исполняющей системы FB. Это означает, что изменяется ВНУТРЕННЕЕ состояние исполняющей системы, чего быть не должно. В этом смысле FB содержит глюк. А с чем он связан, можно только догадаться, проверяя свои триггеры/процедуры.
Я выяснил, что в данном случае FB плохо переваривает рекурсивные процедуры. Например после перекомпиляции всех процедур запрос один раз исполняется правильно и до конца, а последующие вызовы того же самого запроса глючат, пока опять не дашь команду на перекомпиляцию всех процедур. Видимо перекомпиляция всех процедур чего-то там в FB прочищает (может стек, может память, может какие-то переменные).
Переписал процедуру на нерекурсивную - сразу полегчало.

Sergey13 (2006-10-17 08:29:00) [3]
> [4] Dik59 (17.10.06 07:33)

Судя по отсутствию ответов с 21:44 до 07:33 люди спят по ночам, а не решают чужие проблемы. 8-)
Вместо того чтобы искать глюки у других, надо поискать их у себя - например в тригерах/процедурах явно и неявно вызываемых при вставке записей. Так как у других вставляется и по одной и по многу.

Sergey Masloff (2006-10-17 08:22:00) [4]
вероятность глюка на эту тему в fb ничтожно мала. просто на основании приведенных данных обоснованый ответ не дашь.

Dik59 (2006-10-17 07:33:00) [5]
Похоже, по отсутствию советов, что все-таки имеет место глюк в FB, буду обращаться к разработчикам. Спасибо за подтверждение моего предварительного диагноза.

Dik59 (2006-10-16 21:44:00) [6]
В дополнение еще один вопрос.
Исполняю добавление записей запросом:

insert into dms (doc,def,def_,str)
select doc,def, -1,name from def where name is not null and doc = 0

и получаю сообщение:

Too many concurrent executions of the same request

Набор свтавляемых строк, поднимаемых подзапросом

select doc,def, -1,name from def where name is not null and doc = 0

состоит из пяти записей, каждую из которых я без всяких проблем вставляю по одной записи в таблицу dms:

insert into dms (doc,def,def_,str)
select doc,def, -1,name from def where name is not null and doc = 0
and def=XXXX
где XXXX - поочередно беру из каждой поднятой записи.

Вопрос: почему вставка записей поодиночке проходит, а набором - нет?

Dik59 (2006-10-16 20:27:00) [7]
Делал, результат тот же самый

Desdechado (2006-10-16 20:25:00) [8]
на "нечетных" разах нужно делать RollBack, т.е. откат транзакции
тогда на "четных" не будет конфликтов

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »