Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2004.07.18;
Скачать: CL | DM;

Вниз

Row cannot be located for updating. Some values may have been cha   Найти похожие ветки 

 
Bless ©   (2004-06-25 10:48) [0]

1) как обработать ситуацию

У клиента в DBGrid-е посредством запроса (ADODataSet) оказались некоторые данные. При попытке изменить что-то в некоторой строке возникает ошибка

"Row cannot be located for updating. Some values may have been changed since it was last read"

потому что другой пользователь в это же время изменил эту строчку.

Нужно, чтобы данные все-равно были записаны, затерев то, что уже записал другой пользователь в эту строчку. Можно, конечно, обновить эту строчку с сервера и попробовать записать еще раз, но может есть варианты без обновления с сервера?

2) Как наложить блокировку на данные, выбранные ADODataSet-ом до тех пор, пока пользователь не закончит работать с этими данными (например, нажав кнопочку "записать")

И еще, я слышал мельком от нескольких человек, что для многопользовательских систем нужно использовать не data-aware компоненты. Так ли это?

Да и вообще, хотелось бы услышать от людей, которые занимались разработкой многопользовательских систем, несколько общих рекомендаций, по поводу чего делать нельзя, а что нужно.
Например
1) используй/не используй то-то то-то
2) если есть опасность работы с таблицей одновременно нескольких пользователей, всегда делай...
и т.п.

А еще лучше, подкиньте, плз, ссылку на литературу, где подобные вопросы хорошо освещаются.


 
Sandman25 ©   (2004-06-25 10:52) [1]

1. Обновлять по неизменяемому ключу, а не по всем полям записи. То есть
update .. where id = :old_id, а не where id = :old_id and field1 = :old_field1 и т.д.


 
Bless ©   (2004-06-25 11:09) [2]

Sandman25[1]>
Это с помощью ResyncCommand и UniqueTable?

Спасибо, совсем забыл, что есть такой способ.
Пожалуй, я так и сделаю.

А как насчет общих рекомендаций?:)


 
Sandman25 ©   (2004-06-25 11:10) [3]

[2] Bless ©   (25.06.04 11:09)

>Это с помощью ResyncCommand и UniqueTable?

Не знаю, никогда с ADO не работал.

>А как насчет общих рекомендаций?:)

Мне не нравится идея локировать весь набор данных, который пользователь хочет посмотреть. Локировка должна быть как можно короче, только на время непосредственного изменения. Обычно.


 
Курдль ©   (2004-06-25 11:51) [4]

А вы еще спрашивали, чем мне не нравится ADO и MS SQL :)))


 
Bless ©   (2004-06-25 12:03) [5]

>Не знаю, никогда с ADO не работал.
А чем ты его заменяешь?


 
Sandman25 ©   (2004-06-25 12:09) [6]

[5] Bless ©   (25.06.04 12:03)

Раньше BDE, теперь dbExpress.
Но с MS SQL я тоже никогда не работал. Только не спрашивайте, чем я его заменяю :)


 
Bless ©   (2004-06-25 12:16) [7]

Ясненько, спасибо.



Страницы: 1 вся ветка

Текущий архив: 2004.07.18;
Скачать: CL | DM;

Наверх




Память: 0.48 MB
Время: 0.044 c
1-1089106905
YA
2004-07-06 13:41
2004.07.18
траблы с библиотекой


11-1076769216
RA
2004-02-14 17:33
2004.07.18
Меня часто вспрашивают: "А зачем оно надо?".


1-1088808759
GuAV
2004-07-03 02:52
2004.07.18
ShellTreeView


11-1076697668
DDA
2004-02-13 21:41
2004.07.18
DecompressBuf в KolZLib


3-1087986665
Leech
2004-06-23 14:31
2004.07.18
Переносимость базы...