|
|
Регистрация | << Правила форума >> | FAQ | Пользователи | Календарь | Поиск | Сообщения за сегодня | Все разделы прочитаны |
|
Опции темы | Поиск в этой теме | Опции просмотра |
#1
|
||||
|
||||
Отображать только "изменённые записи"
Задача такая: есть связанные таблицы:
Документ <- Изделия. При создании нового документа открывается модальная форма, где вводятся параметры документа, а также заполняется подчинённая таблица с изделиями. Пользователь заполнял таблицу изделий через MemoryDataSet, который потом я проходил циклом и добавлял в уже реальную таблицу на сервере через ADOCommand. Потом подумал, что от этого 5го колеса (MemoryDataSet) можно избавиться вот так: Код:
TADODataSet.FilterGroup := fgAffectedRecords Только вот теперь понять не могу, что писать в сам TADODataSet в качестве запроса, чтоб не тащить все 300тысяч изделий По факту можно и полностью пустой DataSet обрабатывать. Адекватным ли будет запрос: Код:
Select * from items (изделия) where ID = -1 |
#3
|
|||
|
|||
Возможно покажусь занудой...
Ну вот опять же, связка Firebird - FIBPlus решает эту проблему без всяких костылей. |
#4
|
||||
|
||||
Я потихонечку вникаю в FB.
Хотелось бы добить вопрос на уровне mySql. Как получить пустой открытый DataSet? (т.е. DS который можно было бы отобразить в DBGrid и добавлять туда новые записи) Я понимаю, что "-1" - это беда Переспрашиваю, по привычке =\ |
#5
|
||||
|
||||
Цитата:
В таком случае предлагаю честно Надо же, под Interbase теперь IBDAC есть. Эх! Не стоит путать форумы с богадельнями. © Bargest |
#6
|
|||
|
|||
Возможно я поторопился, предлагая перейти на FB. Просто я не в теме про мускул, а он сильно подрос за последнее время. Посему, конечно в первую очередь нужно смотреть расширенные компоненты на стороне клиента, а уже потом на другую СУБД.
Про UniDAC не слышал, но спасибо, что упомянули, обязательно попробую их, мощная штука. А слово "движек" в контекств UniDAC меня несколько смутило. Последний раз редактировалось kaakaa, 04.09.2014 в 20:14. |
#7
|
||||
|
||||
Цитата:
Не стоит путать форумы с богадельнями. © Bargest |
#8
|
|||
|
|||
Запрос вполне годится, только можно сделать еще проще.
1. С всегда ложным условием: Код:
select * from Table where 1=0 Код:
select * from Table limit 0 Код:
select Top 0 * from Table С другой стороны, а что тебе мешает сделать нормально: 1. Добавляем TUpdateSQL (или как он там называется) и прописываем в нем запросы на Insert, Update, Delete. 2. Стартуем транзакцию. 3. Открываем TQuery в нормальном режиме и работаем с ним. 4. Закрываем транзакию (COMMIT для сохранения, ROLLBACK для отмены изменений). |
#9
|
|||
|
|||
Я тоже предлагал такой вариант.
Но недостатком является длинная WRITE транзакция, которая блокирует измененные данные до коммита, а это может быть довольно долго. Ну и как я уже говорил - это плохой тон. |
#10
|
||||
|
||||
Цитата:
Не стоит путать форумы с богадельнями. © Bargest |
#11
|
|||
|
|||
Я вот про что.
Тетя создала документ, добавила к нему товар, и начала этот товар редактировать, а потом ушла пить, чай. А транзакция то не завершена. В результате другие пользователи не смогут работать с этим товаром. Понимаете о чем я? Суть транзакция я правильно понимаю? И что хорошего в таком подходе? |
#12
|
||||
|
||||
Цитата:
Редактирование, как таковое, может касаться, например клиента. Но и в этом случае: просто редактировать клиета никто не будет, редактируют тоже для исправления ошибок. |
#13
|
||||
|
||||
Хорошо, то что никто Тете не подгадит своими изменениями пока она чай пила с подружками. А вообще, транзакцию можно реализовать по разному, можно в лоб, пока не закончится редактирование некой сущности, а можно ведь и частями по окончании некоей логической операции.
Жизнь такова какова она есть и больше никакова. Помогаю за спасибо. |
#14
|
||||
|
||||
Цитата:
Третий пункт не ясен. Открываем TQuery с каким запросом, чтоб не тянуть все записи из таблицы? Транзакции давно реализованы и проверка на доступность сервера (offline режим) хорошо себя показывают вот уже год как. |
#15
|
|||
|
|||
Цитата:
Ну собственно, я высказал опасения. Если вы считаете, что такие ограничения вам не помешают, значит можно этот метод использовать. Но кэширование изменений тут явно пошло бы на пользу (ИМХО). |