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

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

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

TAdoQuery - "обновление"??? при удалении записи [D7, MSSQL]

Rav © (2007-02-18 15:46:00)
Доброго времени суток!

Подскажите, уважаемые, что за глюк!
На форме лежит 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 при изменении запись сначала удаляется из базы и снова туда заносится.
Получается замкнутый круг.... Просвятите плиз! Можно на мыло
Заранее спасибо!

Rav (2007-02-18 17:41:00) [1]

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

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

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

Anatoly Podgoretsky (2007-02-18 17:27:00) [2]
> Rav (18.02.2007 17:06:10) [10]

А надо AdoCommand

sniknik (2007-02-18 17:07:00) [3]
вообще SET NOCOUNT ON в начале ставят, а в конце выключают.

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

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

Rav (2007-02-18 17:06:00) [4]

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

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

Rav (2007-02-18 16:56:00) [5]
Странно, но после удаления вроде бы обычного триггера на удаление из этой таблицы ругаться перестало. Может триггер кривой, посмотрите:
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 НЕ МЕНЯЕТСЯ! В других таблицах это работает без глюков

Anatoly Podgoretsky (2007-02-18 16:51:00) [6]
> Rav (18.02.2007 16:23:06) [6]

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

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

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

Rav (2007-02-18 16:23:00) [8]
да, еще....
ругаться - ругается, а запись из таблицы удаляется

Rav (2007-02-18 16:20:00) [9]
запрос самый обычный
select * from SR_OPGROUPS order by ID

sniknik (2007-02-18 16:14:00) [10]
> Ключевое поле присутствует:
> CREATE TABLE ...
не про таблицу речь, а про запрос.

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

Rav (2007-02-18 16:07:00) [11]
Ключевое поле присутствует:
CREATE TABLE SR_OPGROUPS (
ID int NOT NULL ,
NAME str64 NULL ,
NOTES str255 NULL ,
CONSTRAINT PK_SR_OPGROUPS_ID PRIMARY KEY CLUSTERED (ID)
)

MsGuns (2007-02-18 16:00:00) [12]
Используйте Primary Key и Autoincrement

sniknik (2007-02-18 16:00:00) [13]
ключевое поле в запросе с обновлениями обязательно. (есть вариант когда работает и без него, но через задницу, за счет скорости обновлений, составляя уникальное значение для поиска обновляемой записи из всех полей запроса)

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

Наверх

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