| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Delphi: Базы данных и репортинг > Ввод (редактирование) данных в ДБГриде |
| Автор: AKN 18.4.2006, 10:15 |
| есть такая тема: у меня на форме обычный DBGrid. Если я сделаю запрос к удаленному серверу через Query (обычную выборку) и отображу его в Гриде, а потом ручками поменяю значения нескольких ячеек непосредственно в DBGrid`е - как потом это все отправить на удаленный сервер, чтобы мои исправления в ДБГриде сохранились в БД? |
| Автор: Savek 18.4.2006, 11:19 |
| Post |
| Автор: Palladin 20.4.2006, 23:35 |
| допустим тебе нужно с 5 формы отправить на сохранения в первую форму тогда вроде бы так form1.adotable1.post; |
| Автор: x77 21.4.2006, 10:42 |
| AKN, всё зависит от СУБД и запроса, использованного в квери. ты думаешь, почему на всех форумах по программированию БД требуется указывать, как минимум, используемую субд и используемую технологию доступа? я могу понять твой вопрос, как реализацию трёхзвенки, где удалённым сервером является remote data module, а сервер он потому, что зарегестрирован, как сервер DCOM, и обращение к нему происходит через инициализации его интерфейсов на клиенте. и тогда, чтобы "запостить" к нему данные, тебе придётся заюзать DataSetProvider, либо перегнать данные в XML, а на стороне сервера распарсить их обратно в данные, и всю вставку возьмёт на себя сервер приложений, которому вообще будет пофигу, что ты запостил в своём гриде на другом конце сети. правда, весело? если исходить из того, что юзается "обычная" реляционная субд, и предположить, что под "обычной" Query подразумевается BDE-шная TQuery, то: 1. Как отрабатывается механизм транзакций? если они стартуются явно, то и коммит надо делать явно. 2. Используются ли кэшируемые обновления? если да, то юзать надо ApplyUpdates. это надо делать "помимо" собственно вставки данных. теперь о данных. 3. данные можно "отправить на сервер" тремя способами. 3.1. наглым изменением данных в гриде и вызовом Query1.Post. это самое простое и самое ненадёжное. никто не гарантирует, что этот Post вообще отработает. свойство TQuery.RequestLive по умолчанию находится в FALSE, а именно это свойство отвечает за то, будут ли данные в квери редактируемыми. о и после того, как его поставили в TRUE, оно всё равно не гарантирует, что изменения будут проходить, потому что дальше это зависит уже от того, как составлен запрос. Например, если там присутствуют некоторые виды join'ов, или Union, такой запрос редактировать нельзя в принципе. т.е. до выполнения запроса взводим RequestLive в TRUE, открываем запрос, меняем данные, вызываем Post, и молимся, что запрос позволит изменить эти данные. 3.2. Используется так называемый TUpdateSql. это полуавтоматическая приблуда, которая позволяет выполнять вставки/изменения/удаления данных "независимо" от квери. она кидается на форму, по одной для каждой квери, у квери указывается UpdateObject, двойным кликом открывается UpdateSql и в нём указывается, по каким ключевым полям какие данные меняются. По большому счёту, там можно задать запросы на редактирование вообще левых таблиц, и при этом редактирование их будет происходить при вызове методов редактирования "твоего" запроса. это - оптимальный способ по соотношению надёжности к количеству требуемого кода. т.е. для использования просто юзаются обычные методы TQuery - Insert/Edit/Delete/Post, а связанный с квери TUpdateSql сам отработает все эти методы. 3.3. как гласит старая еврейская мудрость, "хочешь сделать хорошо - сделай это сам". в серьёзных проектах отображение данных всегда отделено от модификации данных. Пусть будет квери, чего-то показывающая на экране. но кроме неё обычно пишется функция, которая выполняет произвольный запрос на произвольной базе с произвольными параметрами. На каждую квери составляются три параметрических запроса, вставляющих, изменяющих, и удаляющих данные. все они объявляются где-нибудь констатнтами. теперь, когда надо, например, вставить данные, юзеру показывают форму, где он эти данные вводит, засовывают их в массив, вызывают ту самую функцию, передают ей запрос на вставку первым параметром, и массив с данными - вторым параметром. и отслеживают выполнение функции. --------- это если очень и очень вкратце. а вообще, такие вот скромные вопросы, типа, как вставить данные, как написать программу, - это нормальная, живая тема как минимум - для курсовой, а то и дисера. |
| Автор: AKN 21.4.2006, 12:45 |
| просто хотелось бы узнать, можно ли вводить данные непосредственно в таблицу, а не в эдиты с последующим insert или update. У меня, например ситуэйшн - каждый день операторам нужно вбить выручку по более чем 300 точкам. Сейчас это организовано так: - юзверь нажимает кнопку "Ввести выручку" - ему выкидывается форма с одним эдитом и комбобоксом (там их больше, но это не главное) в комбобоксе он выбирает точку, в эдите вводит выручку и нажимает "Провести". Сами понимаете, сколько времени это требует. Хотелось бы дать им просто список всех точек, напротив которого можно было бы непосредственно вводить выручку. Это дасть огромный выигрыш во времени заполнения. Есть мысль выкинуть им стринггрид, который они смогут заполнять, но это геморой... Можно ведь сделать проще, не так ли? |
| Автор: x77 21.4.2006, 13:32 |
| можно, но надо знать, как хранятся выручки и точки. дай структуру этих таблиц, плз. смысл в том, чтобы составить запрос, который вытащит все данные одной таблицей, прикрутить к нему грид, TUpdateSql, и прописать соответствующие запросы в TUpdateSql. |
| Автор: AKN 21.4.2006, 13:56 |
| Эта тема, собственно, продолжение http://forum.vingrad.ru/index.php?showtopic=88934 там, в принципе, все описано... |