Ошибка при добавлении/редактировании записи

← →
Jonny210 (2005-06-29 08:56) [0]

Возникла проблема требующая быстрого решения.
Доступ к данным - ADO
При добавлении/редактировании записи вылетает такой эксепшин
"Row cannot be located for updating. Some values may have been changed sinse it was last read.".
Получается какая-то метофизика, ибо добавление/редактирование звписи происходит успешно. Так как все работает, мне нужно просто избавиться от этого сообщения, но все остальные эксепшены мне необходимо отображать.

Ошибка вылетает в методе Update интерфейса Recordset15.

← →
size=20 (2005-06-29 09:49) [1]

> Ошибка вылетает в методе Update интерфейса Recordset15.

и на фиг он тебе нужен. когда есть нормальные методы датасета: пост, едит, кансел?
а насчет ошибки: кажись первичный ключ отсутсвует.

← →
jonny210 © (2005-06-29 10:28) [2]

>> Ошибка вылетает в методе Update интерфейса Recordset15.

>и на фиг он тебе нужен. когда есть нормальные методы датасета: >пост, едит, кансел?
>а насчет ошибки: кажись первичный ключ отсутсвует.

Метод датасеты Post вызавает TCustomADODataset.InternalPost
Который вызывает Recordset.Update.

← →
Anatoly Podgoretsky © (2005-06-29 10:30) [3]

Jonny210 (29.06.05 08:56)
Ну ты наверно изменил данные в записи и теперь ее нельзя найти, а ключа как сказали у тебя наверно нет.

← →
size=20 (2005-06-29 10:42) [4]

> Метод датасеты Post вызавает TCustomADODataset.InternalPost
> Который вызывает Recordset.Update.

и нафиг? учите элементарные основы построения БД: ПК хотя-бы.

← →
jonny210 © (2005-06-29 12:53) [5]

>> Метод датасеты Post вызавает TCustomADODataset.InternalPost
>> Который вызывает Recordset.Update.
>
>и нафиг? учите элементарные основы построения БД: ПК хотя-бы.
Это код не мой, а Borland.!

← →
jonny210 © (2005-06-29 12:57) [6]

Anatoly Podgoretsky: Ключ есть, Identity Increment.

← →
Плохиш © (2005-06-29 13:00) [7]

> jonny210 © (29.06.05 12:57) [6]
> Anatoly Podgoretsky: Ключ есть, Identity Increment.

1. Ты этот ключь не включил в запрос
2. Запрос сложный и в нём просто невозможно разобраться как должны обновлятся все используемые в нём таблицы.

← →
Anatoly Podgoretsky © (2005-06-29 13:32) [8]

← →
АлексейК (2005-06-30 08:52) [9]

Метод датасеты Post вызавает TCustomADODataset.InternalPost
Который вызывает Recordset.Update.

Следовательно в вашем коде используется все таки метод TAdoDataSet.Post?

Поскольку ключ есть и это инкрементное поле, то измениться он не может. Однако если сервер возвращает number of rows affected <> 1, то тогда система считает что произошол конфликт обновления, и выдает ошибку Row cannot be located for updating - что означает строка для обновления не найдена. Следовательно то что происходит редактирование записи ничего удивительного нет, а вот при обновлении набора данных возникает ошибка. Данная ситуация возможна при использовании триггера, что бы ее избежать можно в начале тела триггера поставить команду SET NOCOUNT ON.

Возможна и другая ситуация. Допустим у вас на сервере есть поля, которые заполняются сервером (автоинкрементное, по-умолчанию, триггером). Вы вставили заппись, заполнив не все поля, сервер заполнил остальные. Если не обновить эту запись и попытаться ее отредактировать, то тоже может появится эта ошибка. Для ее разрешения самый простой способ (но далеко не самый элегантный) перед редактированием обновить набор данных. Чуть сложнее обновить только одну запись набора данных. Еще можно самому посмотреть и выставить значение свойств Update Criteria, adCriteriaUpdCols.
Кстати подобная ошибка может возникнут, если другой пользователь изменил эту запись, а в вашем наборе данных устаревшие значения.

Еще можно использовать команду update ... set .... where ..., а набор данных не посредственно не редактировать, правда после этой команды вам придется его обновить (весь или одну строку).

> Еще можно самому посмотреть и выставить значение свойств Update Criteria, adCriteriaUpdCols.

adCriteriaUpdCols - это поиск при апдейте по тем полям что изменились...
как раз если это же поле было изменено кем то другим, будет возникать подобная ошибка.
правильнее (если хотим чтобы последующие изменения были главные) ставить всетаки по ключу (adCriteriaKey), проблем с заменой значений не будет даже если их поменяли за время как у вас прошол прием данных (только при удаленной), это и быстрее к тому же.

>> АлексейК (30.06.05 08:52) [9]
Огромное, человеческое спасибо. От ошибки избавился добавив в триггер SET NOCOUNT ON.

Ошибка при добавлении/редактировании записи Найти похожие ветки