Люди, каким образом происходит Update через TDBGRid?
Есть необходимость делать обновление данных через грид в котором есть 5 колонок. После того как данные изменяются ко мне на сервер приходит сумасшедшее количество Updat'ов. 

Мне кажется что при Update одной строчки на каждое поле одной записи запускается по 1 запросу Update. Так ли это? Если да, то как этого избежать? 

нет.

какие компоннеты доступа к СУБД используешь?

Модификация одной записи одной таблицы - один update.

хе.  Ты даешь гарантию на все компоненты доступа к БД ?

Хмм. Человека интересует:

На сколько я понимаю, дело обстоит следующим образом: TDBGrid говорит датасету, когда выполнить post и соответственно произвести update -> количество post-ов будет определять DBGrid. На модификацию одной записи DBGrid датасету скажет сделать один пост. Если компонент доступа к данным во время выполнения поста пошлет 1-н update, то я прав. Если он пошлет несколько update-ов, в чем очень сомневаюсь, то это не правильные пчелы, которые едят неправильный мед . На свалку такой компонент доступа.

Fedia, 
Зачем так горячиться? Компоненты доступа - одна песня, источник данных - другая. А в сумме - можно иметь разное совершенно количество update. BDE, DBExpress, ADO - совершенно по-разному кэшируют данные и обновляют. А есть еще UpdateMode, Cached Updates и куча чего, крутящегося ручками. Так что пока имеем "ошибку в 17 строке". Достаточно например, не определить явно, какие поля из таблицы идут в датасет, и будет обновляться схема данных.

SergeBS, 

Лучше быть холодным или горячим, чем теплым. Но это оффтопик. Сорри.
Заголовок темы:
Цепочку отправки update-ов при работе в TDBGrid я описал. Если я нигде не ошибся, то она верна в случае отсутствия дополнительных обработчиков событий, написанных "ручками".

. Так можно ли привести пример, в котором при модификации одной записи одной таблицы на сервер БД поступит более одного update-а ? (в случае если в ручную не попортить стандартную схему потока данных).


Да вроде вопрос конкретный, ели не брать во внимание возможные ошибки разработчика программы.

Fedia,

А насчет Cashed Update как? К DBGrid оно никаким боком не относится, и "ручками" тоже не надо работать. Например.
Это я к тому, что DBGrid может "попросить", так сказать, update, но что будет в результате - не от него зависит. Поэтому, без уточнения, что за БД, что за компоненты доступа к данным применяются - "ошибка в 17 строке".


Уже привел:

Подробнее (на примере ADO): кинул на форму ADOTable, подключил к таблице, Fields Editor не вызывал: при любом обновлении вначале будет считываться схема данных таблицы, а потом уже - обновляться поля.

Хех. Может я чего-то не понимаю, но это же не несколько update-ов. Это выборка структуры и 1-н update.

Fedia, 

Скорее всего так, так что пример получился неудачный. Попробую изложить точнее:
DBGrid не определяет ни количество запросов, ни количество update. Это Data Control - элемент отображения, а не доступа. Я видел, например, систему, в которой нужно было заполнять несколько разных форм, касающихся одной записи, а данные запоминались только после заполнения последней. О разумности такого подхода  я говорить не хочу. Просто если полей в записи много и они не умещаются в одну форму, то вполне получим - изменение 1 записи (не 1 поля!) - несколько update.

Начинаю обижаться  Я не утверждал, что DBGrid - это компонент доступа. 

В вопросе автора ветки такого условия таки не было 

Fedia,

А у него вообще НИЧЕГО по поводу обновления не было. Например: к этому гриду докину 2 кнопки:
commit и rollback. Дальше буду работать в этом гриде сколько хочу (ну почти сколько хочу  ), но обновления отсылать или отвергать - по нажатию на кнопку. Сколько будет update? Особенно если кэш на клиенте и размером с таблицу? Другой вариант - отсутствие кэша вообще. Не DBGrid рулит,
сколько и каких update делать. Потому и "ошибка в 17 строке", т.е. - телепаты в отпуске. Какой сервер, какой доступ - я гадать не собираюсь. Немного цитат из док:


Вопрос: сколько будет update, если я изменил 1 запись? 

Да, он рулит необходимостью осуществлять или нет пост.



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

Сорри, не мог доступится к форуму. Только прочел. 

Именно. Я смотрел сколько и что он постит, так вот при кажом update он посылал всю таблицу!

При условии репликации данных это просто ужас. 

СУБД MS SQL. Технология доступа ADO, толстый клиент.

Спасибо за ответы. Скоро отпишусь, если поборю. Если у кого есть идеи как, можете описать. 
Пасип.

Mephisto, 
Свойство MarshalOptions у TADODataSet установить в значение moMarshalModifiedOnly. За эту инф. спасибо SergeBS.
По свойствам ADO почитать можно здесь. Правда, перевод корявый, но понять что к чему можно.

Это сообщение отредактировал(а) Fedia - 11.8.2006, 14:25

Mephisto, 
Получается, что я телепат 

Fedia, 

Еще посмотри options у DBGrid (dgCancelOnExit=true by default). Совсем все неправильно. Вообще, куча значений по умолчанию - остались от прошлого века и Win 3.1. 
А с этим - не знаю зачем такое. Единственное, что в голову приходит: при переходе с BDE на ADO новичок получит на хохме с MarshalOptions тормоза и проблемы, а в результате либо вернется к BDE, либо ломанет в dbExpress. 

SergeBS,  я вот думаю, может эту информацию предложить вынести в раздел "Важно", примерно под таким названием: "Нерациональные настройки по умолчанию компонентов доступа и работы с БД" ? Ведь это на самом деле важная информация, причем не только для новичков.
1. Компонент TADODataSet. Для предотвращения избыточного количества update-ов отправляемых на сервер БД рекомендуется свойство у  MarshalOptions установить  значение moMarshalModifiedOnly.

2. DBGrid…. 
Думаю, примерно в таком духе….

Получается да. 

Пасип. ;)

Fedia, 
Не знаю откуда цитата, но по мне так лучше 1 в 1 перевод доки из хелпа.

Этим Vit рулит, и тогда уж надо излагать про кучу параметров. Поскольку играя ими можно "уронить" скорость элементарных операций до 20 раз (для dbf-локально во всяком случае, это проверено). А в сети, да с сервером все еще страшнее. Тут уже столько всякого полезет, что хоть монографию пиши.

Ага, это и есть перевод хелпа.


Млин, монографию я пока не потяну, да и врятли кто-то мне с этим поможет. У тебя бы наверняка лучше получилось, т.к. налицо твоя большая информированность в этом вопросе.  Я со своей стороны попробую пособирать инфу по этой теме и если созрею, то выложу ее на форум.

ЗЫ: надеюсь без обид, что я на ты, ведь в инете в основном принято такое обращение 

Fedia, 
Боюсь, что пересказ. Не Архангельский, случайно?
Перевод:
--------
Используйте MarshalOptions когда компонента набора данных (dataset) применяет курсор со стороны клиента и изменения данных должны быть посланы обратно на сервер. MarshalOptions определяет, какие записи в локальном наборе записей (recordset) должны быть посланы промежуточному уровню или серверу. Значение moMarshalAll приводит к тому, что все записи локального набора записей упаковываются и отсылаются обратно. Значение moMarshalModified отсылает обратно только те записи, которые действительно были изменены в локальном наборе. Значение MarshalOptions по умолчанию - moMarshalAll.
--------
Обрати внимание: ни слова о скорости соединения.

Я медленно пишу. Пока время найдется, пока нужные выражения в голове прорежутся - на 3 странички - 3 недели уходит. Но до набора хинтов по работе с ADO я уже дозреваю. Может в октябре что и будет . Да, где-то в 2001-2002 я для себя сделал перевод 23 главы "Работа с компонентами ADO". (Delphi 5 Dev. guide). Наверно полезно бы куда закинуть, но куда?
Можешь взять на себя задачку - выяснить куда это пульнуть? Все-таки (с) Borland. 

Взял здесь: _http://www.kti.ru/data/182/index.html. Может быть и Архангельский, там (с) не указан.

В российском инете на зарубежные кооперайты редко обращают внимание. Просто спрос на русский хелп наверное будет не большой. Новички читают (если читают вообще) популярные на текущий момент книги, а профи, даже на среднем уровне зная английский, приспосабливаются читать на нем хелпы и доки. Я думаю, полезно будет написать материал, типа: "Не делай этого - убьет !!!". Не оставляй такие дефолтные свойства: чревато тормозами, не используй такие-то параметры функции: не надежно и т.п. А попроситься разместить такой материал например можно будет здесь: _http://www.delphimaster.ru/articles.html. На этом сайте, кстати, довольно мощный раздел форума по БД (может самый мощный в российском инете по составу участников).

Fedia, 
Точно не он.


Лениво проситься. У меня и так есть, кому надо - пусть попросит.