Можно ли по активной транзакции определить, используется ли она только для чтения или ею внесены изменения в БД (требуется commit)?

Нет. А смысл? Разве ты сам не знаешь, чего в своей транзакции делаешь?

делает пользователь.я могу только следить. на одной транзакции несколько датасетов(заголовок накладной и несколько страничек). Могу отслеживать BeforePost для каждого ДатаСета, но логичней было бы смотреть за транзакцией.

> [2] Евгений Р.   (21.08.08 16:41)
> но логичней было бы смотреть за транзакцией.

ИМХО, странная у тебя логика.

> на одной транзакции несколько датасетов(заголовок накладной
> и несколько страничек).

Ну представь, что узер ввел заголовок и ЧАСТЬ "страничек" (или вообще их не вводил). Ты посмотрел - есть незакомиченные данные и закомитил. И что в итоге?

> Евгений Р.   (21.08.08 16:41) [2]


Видите ли, сэр, все реальные пацаны в своих реальнопацанскихпрогах, как правило, используют минимум ДВЕ транзакции - одну для чтения, другую для модификации. И потому у реальных пацанов такие дурацкие по сути проблемы не возникают ..

> [4] Сергей М. ©   (21.08.08 16:55)

Я конечно ни разу не реальный пацан и всю жизнь пользуюсь одной (за редким исключением) транзакцией, но таких проблем у меня не встречалось. Вывод - не в количестве дело.

Дело в том, что некоторые товарисчи никак не могут отказаться от сеточных редактирований, при этом не затрудняя себя пониманием того, "как это все работает". Отсюда и недоумения

>  [3]

под страничкой я подразумеваю дбГрид с датаСетом
данные в грид можно вводить только после ввода заголовка (после post)
после ввода каждой строки в гриде - пост
по окончании вода документа - commit
необходимо делать commit и по ходу ввода  (чтобы забронировать товар), если оператор заснул на половине заказа. Но после commit нужно переоткрыть датасэты.

т.е. если ничего не ввел - комитить не надо. если введены строки - комитить надо по таймеру и при закрытии документа.

> MsGuns ©   (21.08.08 17:02) [6]


да, если без сеточных редактирований, было бы проще. Но до этого было так на парадоксе. Поэтому пока должно быть так. Ну а при "незатруднении пониманием" не возникает вопросов.

Удалено модератором

"Коммитить" надо любой пост, что автоматически и делается, если асякой фигни не панавыставлять ручками шаловливыми. А вот сам документ должен иметь статус "проведено", который выставлять по команде пользователя когда он введет весь документ. А до того остатки по карточкам не менять.

> MsGuns ©   (21.08.08 20:31) [10]
>
>


> "Коммитить" надо любой пост, что автоматически и делается

а.У tIbDataSet такое не делается, через запрос тоже.
б. "Не надо делать коммит после каждой записи, если это не требуется по смыслу
Это излишне нагружает сервер."  п.7 http://www.cyberguru.ru/database/interbase/interbase-hints.html

уж не знаю кому верить.


> А до того остатки по карточкам не менять.
>

А если операторов много, а товара мало?

> Евгений Р.   (21.08.08 21:26) [11]
>
>

Не надо делать commit после вставки каждой записи, если вы их вставляете больше 10 за один раз
Interbase плохо работает в этом режиме, т.е. вставка будет медленной. Лучше оформить вставки "в пакет" и обрамить их StartTransaction/Commit.
//////
это с твое ссылки...
http://www.cyberguru.ru/database/interbase/interbase-hints.html

я понял, что редактировангие через dbGrid - не популярно здесь.
но если есть такая необходимость, то commit рекомендуете делать автоматом по AfterPost, AfterDelete?

Пункт 7.
Не противоречит сказанному в [10] ибо любая модификация - добавление - удаление записи в режиме ручной работы с документом должна фиксироваться в БД, иначе возникнет эффект "Я вводила - куда она подевалась ?"
В ручном режиме человек физически не сможет загружать сервер обновлениями чаще нескольких раз в минуту и только по одной записи зп раз - для сервера это вообще ничто.

Пункт 8.
Не противоречит ибо за один раз вы изменяете, добавляете, удаляете только одну запись. В этом пункте говорится о том, что если идет "массовое" удаление/добавление/изменение, например в цикле, то следует по возможности весь "пакет" заворачивать в одну транзакцию. При подтверждении каждого изменения в режиме "пулемета" сервер явно может "перегреться"

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

> Это излишне нагружает сервер."  п.7 http://www.cyberguru.ru/database/inte
> rbase/interbase-hints.html
>
> уж не знаю кому верить.


вообще-то оригинальный текст статьи находится здесь:
http://ibase.ru/devinfo/dontdoit.htm

хотя нет, там уже не поймешь, кто у кого :)

Не согласен только с п.20 о вето на Float. В некоторых случаях без него трудно обойтись, а работать с ним вполне можно, соблюдая некоторые простые правила.

> В некоторых случаях без него трудно обойтись


В каких например?

Я обычно делаю проще.

В DataSource на событие DataChange при условии параметра Field <> nil делаю SaveAction.Enabled := True; То же делаю и на событие AfterDelete детальных датасетов.

На Form1.OnCloseQuery документа делаю проверку SaveAction.Enabled и если True прошу юзера все сохранить (проведение и CommitRetaining)  или нет (RollBack) или отмена Form1.CanClose := False.

Еще есть кнопка Save со значком дискеты, которую он всегда нажать может. Там и проведение и CommitRetaining.

А транзакцию я сую в каждую форму. По умолчанию она RollBack.
Благо InterBase не боится множества транзакций. И еще у меня есть одна общая транзакция ReadOnly (read nowait)  в глобальном модуле данных. Это для чтения всяких справочников и прочей фигни, не требующей изменений данных.