свойства tIbTransaction

← →
Евгений Р. (2008-08-21 15:09) [0]

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

← →
DrPass © (2008-08-21 16:15) [1]

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

← →
Евгений Р. (2008-08-21 16:41) [2]

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

← →
Sergey13 © (2008-08-21 16:51) [3]

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

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

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

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

← →
Сергей М. © (2008-08-21 16:55) [4]

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

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

← →
Sergey13 © (2008-08-21 16:58) [5]

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

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

← →
MsGuns © (2008-08-21 17:02) [6]

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

← →
Евгений Р. (2008-08-21 17:25) [7]

> [3]

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

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

← →
Евгений Р. (2008-08-21 17:31) [8]

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

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

← →
Сергей М. © (2008-08-21 17:42) [9]

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

← →
MsGuns © (2008-08-21 20:31) [10]

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

← →
Евгений Р. (2008-08-21 21:26) [11]

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

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

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

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

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

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

← →
Виталий Панасенко(дом) (2008-08-21 22:39) [12]

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

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

← →
Евгений Р. (2008-08-21 22:47) [13]

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

← →
MsGuns © (2008-08-21 22:51) [14]

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

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

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

← →
Loginov Dmitry © (2008-08-21 22:51) [15]

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

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

← →
Loginov Dmitry © (2008-08-21 22:52) [16]

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

← →
MsGuns © (2008-08-21 22:55) [17]

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

← →
Loginov Dmitry © (2008-08-21 23:01) [18]

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

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

← →
kaif © (2008-08-21 23:04) [19]

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

В 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) в глобальном модуле данных. Это для чтения всяких справочников и прочей фигни, не требующей изменений данных.

← →
Sergey13 © (2008-08-22 08:56) [20]

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

Не надо выдавать свои наработанные приемы работы за всеобщее обязательное правило и вводить неопытных пользователей в заблуждение.
Коммитить надо НЕ "любой пост", а транзакцию. Транзакция - это модификация БД переводящая эту самую БД из одного СОГЛАСОВАННОГО СОСТОЯНИЯ в другое. Эта модификация может быть как изменением одной записи так переписыванием половины базы.

← →
MsGuns © (2008-08-22 09:05) [21]

>Sergey13 © (22.08.08 08:56) [20]

[14] прочитай, а ?

"Коммитить" относится к посту или транзакции ? Не надо "вводить в заблуждение неопытных пользователей" ;)

← →
Sergey13 © (2008-08-22 09:16) [22]

> [21] MsGuns © (22.08.08 09:05)
> [14] прочитай, а ?

Именно поэтому и написал свои возражения.
> [14] MsGuns © (21.08.08 22:51)
> Пункт 7.
> Не противоречит сказанному в [10] ибо любая модификация
> - добавление - удаление записи в режиме ручной работы с
> документом должна фиксироваться в БД, иначе возникнет эффект
> "Я вводила - куда она подевалась ?"

НЕ любая, а только переводящая документ из одного согласованного состояния в другое согласованное.

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

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

← →
Евгений Р. (2008-08-22 11:18) [24]

состояние, как я понял - проведен/не проведен?

← →
Евгений Р. (2008-08-22 11:26) [25]

И еще:
наверное параллельно Вы блокируете открытие (или редактирование) документа, открытого одним из пользователей?
Если да, то каким образом:
1.у самого документа есть признак "открыт"
2.есть отдельная таблица с идентификаторами открытых документов
3.отслеживать блокировки документа (не представляю как)

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

Если мне память не изменяет в ФБ реализовано выражение FOR UPDATE в запросе SELECT. Но злоупотреблять им не стоит и использовать следует с осторожностью.

>Sergey13 © (22.08.08 09:16) [22]
>НЕ любая, а только переводящая документ из одного согласованного состояния в другое согласованное.

Интересно девки пляшут. Это если в документе 100 строк, то записывать его в базу нужно только тогда, когда все 100 строк будут введены, а если не успел к закрытию конторы, то с утряка по новой, эге ж ?

> [27] MsGuns © (22.08.08 16:46)

А кто как сделал струтуру БД и приложение - так и делать. Ты же вот делаешь у себя поле "проведено". Это решение для твоего частного случая. Кому то оно не подойдет - ему надо сразу все или ничего. А кому то вообще пофиг - хоть неделю заводи и БД все равно согласованная. Транзакции позволяют работать с любой бизнеслогикой.

>Игорь Шевченко © (22.08.08 16:57) [29]
>А кому нужен в базе документ с 50-ю строками из 100 ?

А кому нужен документ, который за раз сможет ввести только Анка-пулеметчица, и то за сутки непрерывной работы ?

Экие вы странные оба однако. Такое ощущение, что с живыми людьми только на улице общаетесь ;)

MsGuns © (22.08.08 17:06) [30]

Да нет, мы не странные. Просто не стоит свои приемы работы выдавать за непререкаемые истины для всех случаев.

>Игорь Шевченко © (22.08.08 18:39) [31]
>Просто не стоит свои приемы работы выдавать за непререкаемые истины >для всех случаев

Вот и я о том же ;)

свойства tIbTransaction Найти похожие ветки