|
FireDac Transaction
|
|||
---|---|---|---|
#18+
Здравствуйте, до сегодня учился писать на Delphi7. пользовался стандартными IB компонентами. Вопрос в следующем: Перед селективным запросом, я всегда закрывал IBTransaction привязанную к IBQuery через который делал запрос, для того чтобы я видел все изменения в БД, так-как не сбросив IBTransaction, я их не увижу. В коде это примерно так: Код: pascal 1. 2. 3. 4.
Опробовал сегодня бесплатную Delphi 10.3, пробовал FireDac компоненты, но там FDTransaction.Active - read only свойство. Подскажите, как правильно сбросить транзакцию через эти компоненты? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2019, 22:41 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
alexK19, StartTransaction, Commit, Rollback. Active - не надо пользоваться ни где, не только в FireDac ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2019, 22:44 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
Симонов ДенисalexK19, StartTransaction, Commit, Rollback. Active - не надо пользоваться ни где, не только в FireDac Т.е перед выборкой я ее просто перестартовую и все, даже если она активна вызывая метод StartTransaction? использование Active - это просто признак дурного тона? или есть последствия? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2019, 22:59 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
alexK19Перед селективным запросом, я всегда закрывал IBTransaction привязанную к IBQuery через который делал запрос, для того чтобы я видел все изменения в БД, так-как не сбросив IBTransaction, я их не увижу. Трешняк какой-то. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2019, 23:02 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
alexK19использование Active - это просто признак дурного тона? да. Потому что IBTransaction.Active := False; - это хз что, то ли commit, то ли rollback ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2019, 23:07 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
alexK19, если тебе нужно видеть изменения, ты должен либо смотреть на эти изменения в контексте той же транзакции, где эти изменения делались. Либо транзакция, в которой делались изменения, должна быть подтверждена, а транзакция, в которой ты читаешь: - должна стартовать после подтверждения первой транзакции - или иметь право читать изменения, сделанные других подтвержденных транзакциях. А как ты это сделаешь - дело десятое. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2019, 23:10 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
ёёёёёalexK19, если тебе нужно видеть изменения, ты должен либо смотреть на эти изменения в контексте той же транзакции, где эти изменения делались. Либо транзакция, в которой делались изменения, должна быть подтверждена, а транзакция, в которой ты читаешь: - должна стартовать после подтверждения первой транзакции - или иметь право читать изменения, сделанные других подтвержденных транзакциях. А как ты это сделаешь - дело десятое. Ну по сути я так и делаю: вот у меня есть Transaction1 <-> Query1 Transaction2 <-> Query2 после Transaction1.Commit, я должен перестартовать Transaction2, чтобы увидеть все изменения. Другое дело, что Transaction2 должна быть уже всегда закрыта, при изменениях через другие транзакции. Получается, что даже после селективного запроса я должен вызывать Commit, чтобы транзакция закрылась, правильно? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2019, 23:20 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
alexK19я должен перестартовать Transaction2, чтобы увидеть все изменения. ну так не используй snapshot транзакции, используй read committed ! http://www.ibase.ru/ibx/#ibtransaction ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2019, 23:25 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
alexK19что даже после селективного запроса я должен вызывать Commit, чтобы транзакция закрылась, правильно? Неправильно. Переосмысли архитектуру. Транзакции должны стартовать когда это требуется и завершаться так быстро как только это возможно. Если у тебя "после коммита одной транзакции надо рестартовать другую", то что-то смердит в консерватории. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2019, 00:06 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
Я для чтения использую одну читающую транзакцию, которая создается при старте приложения Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
и исполую ее когда мне надо сделать всякие select............. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2019, 10:24 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
Sashaua, сие (долгоживущая "читающая" транзакция) работает, но более не рекомендовано, ибо несёт в себе некоторый негатив. Рекомендуется заливать набор данных в клиентский датасет, подтверждая транзакцию (Commit). ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2019, 11:02 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
ёёёёёибо несёт в себе некоторый негатив. какой? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2019, 11:18 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
02.10.2019 11:02, ёёёёё пишет: > сие (долгоживущая "читающая" транзакция) работает, но более не > рекомендовано, Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2019, 11:21 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
Мимопроходящий, ага. Я напомню: Если раньше транзакция RO RC сразу стартовала как пре-коммиттед, то в ФБ 4 такого нет, это обычная транзакция. НО. В ФБ 4 в конфиге есть переключатель по этому поводу. Кроме того, мусор в ФБ 4 собирается не так, как раньше, что позволяет не париться сильно по поводу RO RC. По поводу "негатива" - это видимо про использование LIST и типа того. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2019, 11:35 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
kdv, ну там не только в LIST дело. Если чтение BLOB отложено, то к моменту когда BLOB реально может быть прочитан по его идентификатору, сам идентификатор уже может протухнуть. С промежуточной сборкой мусора этот сценарий довольно вероятен. Поэтому есть два решения, либо читать содержимое BLOB сразу по мере фетча и кешировать в датасетах (что не очень экономно), либо не выбирать BLOB вовсе в этом DataSet, а дёргать его отдельным запросом по ключу таблицы, когда он потребуется. А про LIST раз уж он используется, то скорее всего для отчётной формы, а раз так, то там с большой вероятностью курсор должен быть вычитан полностью вместе со всеми BLOB ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2019, 12:08 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
Поди тут разберись как правильно делать, наверное только с опытом прийдет. В одной из прочтенных статей настоятельно рекомендуется отключать свойства AutoStart и AutoStop для полного ручного управления транзакцией, но если я буду что-то читать через эту транзакцию, то мне прийдется стартовать ее вручную (StartTransaction). Использовать для чтения отдельные транзакции - плодить компоненты. Использовать одну читающую - не всегда вариант, так иногда хочется чтобы на разных вкладках в DBGridax сохранялся результат. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.10.2019, 23:55 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
alexK19Использовать для чтения отдельные транзакции - плодить компоненты. А их разработчики с тебя деньги берут за каждый экземпляр? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2019, 00:20 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
Всё!!! Спасибо уважаемы, что что-то подсказали и не загнобили новичка. Получается в общем случае в приложении достаточно двух транзакций, как я понял: 1) Первая для insert\update\delete (на нее вешаем все хранимые процедуры, каждая процедура модифицирует определенную таблицу) 2) Вторая для select (вешаем на нее все Query <- DataSource <- DBGrid) для каждой таблички отдельный Query. PS. В первоначальном варианте, на старте обучения наплодил отдельных транзакций на каждую таблицу. Но оно наверное и хорошо, что пришлось пообжигаться на собственном опыте. А все началось с того, что не знал что транзакции бывают "разные" (readcommited , shaphot,....). Но трошки вроде въехал, нужно учиться дальше ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2019, 01:08 |
|
FireDac Transaction
|
|||
---|---|---|---|
#18+
alexK19Поди тут разберись как правильно делать, наверное только с опытом прийдет. В одной из прочтенных статей настоятельно рекомендуется отключать свойства AutoStart и AutoStop для полного ручного управления транзакцией... В опции "AllowAutoStart" ничего страшного нет. В ея нутрях сделано так, что если ты стартовал трансакцию ручками, то потом, когда придет время "Автостопа" - сие учтется: "ага, он тут рукосуйством занимается, ну и мне значит не след завершаться". Удобно: меньше движений при коротких операциях, и в то же время не мешает ручному управлению, если захочется. alexK19... Использовать для чтения отдельные транзакции - плодить компоненты. Использовать одну читающую - не всегда вариант, так иногда хочется чтобы на разных вкладках в DBGridax сохранялся результат. Обычно ты уже представляешь, что тебе нужно при работе. Например, настроек трансакций нужно совсем немного, часто всего две-три: 1)RC+RW, 2) RC+RO и, возможно, 3) снапшот-трансакцию. Поэтому часто удобно создать собственный компонент, инкапсулирующий нужные именно тебе настройки. Например, пусть будет фабрика классов, генерирующая настроенные объекты - "запросы", уже подключенные к объекту коннекта и к настроенной (возможно - созданной тут же) трансакции. В итоге - меньше тупой однообразной работы, и централизованное управление. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2019, 01:15 |
|
|
start [/forum/topic.php?fid=40&msg=39870442&tid=1560557]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
125ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
others: | 266ms |
total: | 482ms |
0 / 0 |