Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2004.07.18;
Скачать: [xml.tar.bz2];

Вниз

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;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.46 MB
Время: 0.045 c
14-1088509025
blackweber
2004-06-29 15:37
2004.07.18
Win98 - сеть - WinXP


14-1088502306
Bacuc
2004-06-29 13:45
2004.07.18
Интерфейс, значки


1-1088583732
Tempo
2004-06-30 12:22
2004.07.18
Диалог выбора папки


3-1087845103
zokzok
2004-06-21 23:11
2004.07.18
изменение таблицы через Query


14-1088489321
ALEIIIKA
2004-06-29 10:08
2004.07.18
Интернет(WAP) через GPRS





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский