[Uniq!]

Задача такая: есть связанные таблицы:
Документ <- Изделия.
При создании нового документа открывается модальная форма, где вводятся параметры документа, а также заполняется подчинённая таблица с изделиями.
Пользователь заполнял таблицу изделий через MemoryDataSet, который потом я проходил циклом и добавлял в уже реальную таблицу на сервере через ADOCommand.

Потом подумал, что от этого 5го колеса (MemoryDataSet) можно избавиться вот так:

Код:

TADODataSet.FilterGroup := fgAffectedRecords

отфильтровав из реальной таблицы только те изделия, которые были "изменены"/"добавлены"

Только вот теперь понять не могу, что писать в сам TADODataSet в качестве запроса, чтоб не тащить все 300тысяч изделий По факту можно и полностью пустой DataSet обрабатывать.

Адекватным ли будет запрос:

Код:

Select * from items (изделия) where ID = -1

[Freeman]

Идея временных отрицательных Id возвращается, ага.

Возможно покажусь занудой...
Ну вот опять же, связка Firebird - FIBPlus решает эту проблему без всяких костылей.

[Uniq!]

Я потихонечку вникаю в FB.

Хотелось бы добить вопрос на уровне mySql.
Как получить пустой открытый DataSet? (т.е. DS который можно было бы отобразить в DBGrid и добавлять туда новые записи)

Я понимаю, что "-1" - это беда Переспрашиваю, по привычке =\

[Freeman]

Сообщение от Uniq!

Хотелось бы добить вопрос на уровне mySql.

Э, а это что, через ADO именно MySQL использовался, а не Access?

В таком случае предлагаю честно украсть купить компоненты MyDAC и перейти на них, если хочется остаться на MySQL. Движок UniDAC -- единственный в моих глазах, заслуживающий уважения, а порой даже и восхищения своей продуманностью и не надуманностью, как случается довольно часто. Не сочтите за рекламу.

Надо же, под Interbase теперь IBDAC есть. Эх!

Возможно я поторопился, предлагая перейти на FB. Просто я не в теме про мускул, а он сильно подрос за последнее время. Посему, конечно в первую очередь нужно смотреть расширенные компоненты на стороне клиента, а уже потом на другую СУБД.

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

[Freeman]

Сообщение от kaakaa

А слово "движек" в контекств UniDAC меня несколько смутило.

Достаточно посмотреть на архитектуру DAC-компонентов под любую СУБД, чтобы сомнения отпали. Вначале на общем уровне добавляются разные вкусности вроде AddWhere и ResultSQL, а потом под каждую СУБД это конкретно реализуется в наследниках.

[lmikle]

Запрос вполне годится, только можно сделать еще проще.
1. С всегда ложным условием:

Код:

select * from Table where 1=0

2. Если поддерживается limit:

Код:

select * from Table limit 0

Вариант для MS SQL Server:

Код:

select Top 0 * from Table

Собственно, примерно так и пришлось один раз сделать, что бы не качать данные на клиента. Нужен был нормальный доступ к TBlobField только для закачки данных.

С другой стороны, а что тебе мешает сделать нормально:
1. Добавляем TUpdateSQL (или как он там называется) и прописываем в нем запросы на Insert, Update, Delete.
2. Стартуем транзакцию.
3. Открываем TQuery в нормальном режиме и работаем с ним.
4. Закрываем транзакию (COMMIT для сохранения, ROLLBACK для отмены изменений).

Я тоже предлагал такой вариант.
Но недостатком является длинная WRITE транзакция, которая блокирует измененные данные до коммита, а это может быть довольно долго. Ну и как я уже говорил - это плохой тон.

[Freeman]

Сообщение от kaakaa

Ну и как я уже говорил - это плохой тон.

Это плохой тон в глазах тех, кто не понимает сути реляционной модели. Транзакция должна длиться столько, сколько нужно, и никаких гвоздей! В сериализующих СУБД (Oracle, PostgreSQL) состояние транзакции является свойством строки, поэтому транзакция почти ничего не стоит. По остальным СУБД нужно читать доку, а не слепо следовать неизвестно кем и когда придуманным догмам.

Я вот про что.
Тетя создала документ, добавила к нему товар, и начала этот товар редактировать, а потом ушла пить, чай. А транзакция то не завершена. В результате другие пользователи не смогут работать с этим товаром.
Понимаете о чем я?
Суть транзакция я правильно понимаю?
И что хорошего в таком подходе?

[Uniq!]

Сообщение от kaakaa

и начала этот товар редактировать

Товар нельзя редактивровать. Здесь все упирается в бизнесс процессы и их понимание. Товар на склад приходит один раз, заводится один раз, привязывается к опр докумнтам (ГТД), после чего "раскидывается"его цена, замораживается. Все, товар для редактирования никому не доступен, только ответственный по ГТД(кладовщик, учетный) имеет право редактировать. И если в это есть необходимость, то невозможность редактировать товар-это даже правильно, ибо созддание счета с неправильным товаром(неправильной ценой, параметрами) - может привести к ошибкам в бух. Учете.

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

[Страдалецъ]

Хорошо, то что никто Тете не подгадит своими изменениями пока она чай пила с подружками. А вообще, транзакцию можно реализовать по разному, можно в лоб, пока не закончится редактирование некой сущности, а можно ведь и частями по окончании некоей логической операции.

[Uniq!]

Сообщение от lmikle

С другой стороны, а что тебе мешает сделать нормально:
1. Добавляем TUpdateSQL (или как он там называется) и прописываем в нем запросы на Insert, Update, Delete.
2. Стартуем транзакцию.
3. Открываем TQuery в нормальном режиме и работаем с ним.
4. Закрываем транзакию (COMMIT для сохранения, ROLLBACK для отмены изменений).

Вы имеет ввиду TADOCOmmand. Мне нужен DataSet, чтоб привязать его к DBGRid, человек должен видеть: что он добавляет, редактирует. А ADOCommand не возвращает DataSet.

Третий пункт не ясен. Открываем TQuery с каким запросом, чтоб не тянуть все записи из таблицы?

Транзакции давно реализованы и проверка на доступность сервера (offline режим) хорошо себя показывают вот уже год как.

Сообщение от Uniq!

Товар нельзя редактировать .

Ну а если она начала редактировать документ, а потом чай ушла пить?
Ну собственно, я высказал опасения. Если вы считаете, что такие ограничения вам не помешают, значит можно этот метод использовать.
Но кэширование изменений тут явно пошло бы на пользу (ИМХО).