TAdoQuery - "обновление"??? при удалении записи

← →
Rav (2007-02-18 15:46) [0]

Доброго времени суток!

Подскажите, уважаемые, что за глюк!
На форме лежит TAdoQuery. CursorLocation = clUseClient, CursorType = ctKeyset. При добавлении, изменении запсей ведет себя совершенно нормально, а при удалении "стандартной" командой Delete
SR_OPGROUPS.Delete;
вылетает исключение: "Не удается найти строку для обновления. Некоторые значения могли быть изменены со времени ее последнего чтения".
Если ставлю CursorLocation = clUseServer - ошибка при удалении пропадает, но при ИЗМЕНЕНИИ записи начинает ругаться MS SQL на нарушение ссылочной целостности (хотя я запись из таблицы и не собирался удалять):
UPDATE statement conflicted with COLUMN REFERENCE constraint "FK_SR_OPGLINKS_GRP". The conflict occurred in database "it_base", table "SR_OPGLINKS", column "ID_OPGROUPS"
Такое ощущение, что при clUseServer при изменении запись сначала удаляется из базы и снова туда заносится.
Получается замкнутый круг.... Просвятите плиз! Можно на мыло
Заранее спасибо!

← →
MsGuns © (2007-02-18 16:00) [1]

Используйте Primary Key и Autoincrement

← →
sniknik © (2007-02-18 16:00) [2]

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

> На форме лежит TAdoQuery
положи вместо него TADODataSet

← →
Rav (2007-02-18 16:07) [3]

Ключевое поле присутствует:
CREATE TABLE SR_OPGROUPS (
ID int NOT NULL ,
NAME str64 NULL ,
NOTES str255 NULL ,
CONSTRAINT PK_SR_OPGROUPS_ID PRIMARY KEY CLUSTERED (ID)
)

← →
sniknik © (2007-02-18 16:14) [4]

> Ключевое поле присутствует:
> CREATE TABLE ...
не про таблицу речь, а про запрос.

.... и, у тебя что за значения в ключе? или CLUSTERED убери, или поле ID автоинкриментным сделай. смысл CLUSTERED имеется только если значения добавляются с приращением, если вразнобой (например рандомом получаемые) то единственное чего добьешся это тормозов на добавлении.

← →
Rav (2007-02-18 16:20) [5]

запрос самый обычный
select * from SR_OPGROUPS order by ID

← →
Rav (2007-02-18 16:23) [6]

да, еще....
ругаться - ругается, а запись из таблицы удаляется

← →
sniknik © (2007-02-18 16:38) [7]

> запрос самый обычный
> ...
ну тогда может действительно "Некоторые значения могли быть изменены со времени ее последнего чтения"? ничего не меняешь, со стороны, в смысле запросами/из других датасетов а не только показанного? значение ключа трогаешь? (если нет, то поставь у датасета после открытия (можно в событии после открытия) ADODataSet1.Properties["Update Criteria"].Value:= adCriteriaKey; это явное указание задействовать ключ для запросов на обновление)

> Такое ощущение, что при clUseServer при изменении запись сначала удаляется из базы и снова туда заносится.
а как ты хотел, небось значение ключа меняешь, вот таблица и перестраивается. (кластеред означает что записи идут в порядке значения ключа... без удаления и записи ее на новое место не поставишь.)

← →
Anatoly Podgoretsky © (2007-02-18 16:51) [8]

> Rav (18.02.2007 16:23:06) [6]

Не используй TAdoQuery

← →
Rav (2007-02-18 16:56) [9]

Странно, но после удаления вроде бы обычного триггера на удаление из этой таблицы ругаться перестало. Может триггер кривой, посмотрите:
CREATE TRIGGER SR_OPGROUPS_DELETE ON dbo.SR_OPGROUPS
FOR DELETE
AS
BEGIN
delete from SR_OPGLINKS where SR_OPGLINKS.ID_OPGROUPS in
(select ID from DELETED)
delete from SU_OPGLINKS where SU_OPGLINKS.ID_OPGROUPS in
(select ID from DELETED)
END

> небось значение ключа меняешь

Неа.... иначе бы не спрашивал
Значение ID формируется для всех таблиц базы единообразно - дело в том, что значение ID нужно уже сразу после DataSet.Applend, а автоинремент даст результат только после сохранения в базе. Поэтому я генерирую ID при вставке процедурой с блокировкой в специальной таблице (дабы несколько пользователей могли одновременно вставлять записи). Затем ID НЕ МЕНЯЕТСЯ! В других таблицах это работает без глюков

← →
Rav (2007-02-18 17:06) [10]

> Не используй TAdoQuery

Использование TAdoDataSet дает такой же результат... :-(

вообще SET NOCOUNT ON в начале ставят, а в конце выключают.

а внешними ключами то же самое не проще?

> Использование TAdoDataSet дает такой же результат... :-(
не связано с вопросом, просто идеологически неверный компонент...

> Rav (18.02.2007 17:06:10) [10]

А надо AdoCommand

← →
Rav (2007-02-18 17:41) [13]

> вообще SET NOCOUNT ON в начале ставят, а в конце выключают.

СЕНКС!!! СЕНКС!!! СЕНКС!!! ПОМОГЛО!
К сожалению пока плохо рабираюсь в таких тонкостях SQL - всему приходится учиться на своих ошибках...

Всем спасибо за помощь!!!!!!!!!!

TAdoQuery - "обновление"??? при удалении записи Найти похожие ветки