Использование транзакций в IB

← →
Term (2003-10-02 11:29) [0]

Вопрос такой как правильно использовать транзакции в IB, так как тут как я понял есть определённые тонкости:
в литературе у меня написанно так:

DataBase1.StartTransaction; try append ..... post DataBase1.Commit; except DataBase1.RollBack; end;

мастера покажите примерчик как оно должно быть, с правильным использованием компонентов TIBDataBase, TIBTransaction, TIBDataSet.

← →
Vlad © (2003-10-02 11:32) [1]

Задача то какая, если не секрет ?

← →
Term (2003-10-02 11:38) [2]

ну в двух словах электронный документооборот, это вообще,
а на данном этапе нужно сохранять данные в несколько связанных таблиц, при этом соотв. чтобы соблюдались условия ссылочной целостности, ну и соотв, нужно использовать транзакции, а в их использование в IB есть определенные тонкости, вот я и спрашиваю как сделать правильно...
Использую компоненты TIBDataBase, TIBTransaction, TIBDataSet

← →
Vlad © (2003-10-02 12:00) [3]

Ну для такой задачи особых тонкостей я не вижу.
Все стандартно: Открыл транзакцию, затем провел изменения в таблицах, подтвердил транзакцию. В случае ошибки - откатил транзакцию.
В твоем примере все верно написано, только про BDE по-моему.

← →
Term (2003-10-02 12:00) [4]

ну ктонить.... хелп

← →
Term (2003-10-02 12:02) [5]

ну да вот именно что для БДЕ, а как для IB???
так как если
TIBDataBase1.StartTransaction
вываливается исключение что Transancion Started
и как сделать правильную обработку, я понимаю что задачка тривиальная, но я новичёк в IB

← →
Vlad © (2003-10-02 12:07) [6]

if not ibtransaction.active then ibtransaction.StartTransaction
......
ibtransaction.commit
....
ibtransaction.rollback

← →
Term (2003-10-02 12:10) [7]

спасибо буду пробывать

← →
MsGuns © (2003-10-02 12:13) [8]

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

1. Транзакция A - все, что отображается
2. Транзакция B - все изменения (TIBSQL) на клиенте как целостная логически завершенная порция (например, при удалении документа сначала удаление из фактуры, затем из таблицы заголовков)
3. Транзакция C - все вспомогательные инф.запросы, не влияющие на отображение (репорты, запросы на неотображаемые таблицы и т.д.)

← →
Vlad © (2003-10-02 12:20) [9]

>MsGuns © (02.10.03 12:13) [8]
Из [2] не видно что у него вобще что либо отображается.
Речь шла вроде о записи в таблицы с сохранением ссылочной целостности ?

← →
Term (2003-10-02 12:30) [10]

я просто не знал как прально спросить, у меня есть грид в котором отображаются данные из базы. я щелкаю по speedbutton"у открываю форму, и с неё сохр. данные, у меня одна транзакция, теперь добавлю еще одну, и значит читать через вторую,
значит перед выполнением запросов, менять свойство компонентов
Transaction, на имя нужной транзакции.
Я правильно понял?

← →
Vlad © (2003-10-02 12:36) [11]

Нет. Если уж так, то для каждого Query своя транзакция. Для пишущего - одна, для читающего - другая. Никаких свойств менять не надо.

← →
Term (2003-10-02 12:40) [12]

понял. спасибо

← →
MsGuns © (2003-10-02 12:48) [13]

>Vlad © (02.10.03 12:36) [11]

Ну если у тебя отображаются три НД через TIBQuery или TIBDataSet, то зачем в общем случае для каждой своя транзакция ? Я бы все три впихнул бы в одну. TIBDataBase-то одна и та же небось

← →
Vlad © (2003-10-02 12:55) [14]

MsGuns © (02.10.03 12:48) [13]
Я же говорил в [11]: пишушие -в одну транзакцию, а читающие - в другую.
Кажется так советуют умные люди :)

← →
MsGuns © (2003-10-02 13:00) [15]

>Vlad © (02.10.03 12:55) [14]
>>MsGuns © (02.10.03 12:48) [13]
>Я же говорил в [11]: пишушие -в одну транзакцию, а читающие - в другую.

Мальчики налево
Девочки направо
;)

← →
Term (2003-10-02 13:11) [16]

У меня 3 связанных TIBDataSet и во всех трех я определил соответсвующие свойства т.е SelectSQL, RefreshSQL,ModifySQL, InsertSQL и DeleteSQL т.е. у меня и пишутся и читаются через одни и теже компаненты, и как быть в этом случае

← →
MsGuns © (2003-10-02 13:42) [17]

Все в одну транзакцию, то подтверждение ее в зависимости от

- 1 вариант "Интерактивный"
После каждого изменения подтверждение/откат для того, чтоб каждое изменение тут же откладывалось на сервере и, как следствие, могло быть отображено на других клиентах
недостаток - загрузка сетки большим кол-вом мелких пакетов

- 2 вариант "По требованию"
Подтвержение по кнопке. Т.е. сосед не увидит изменений, пока ты не щелкнешь по ней.

Как надо в данной ситуации - тебе виднее. С точки зрения эффективности системы второй вариант предпочтительнее.

Кроме того, могут быть ситуации с требованием "комплексности" изменений. Т.е. изменения в таблице 1 не должны быть сделаны без соотв. изменений в табл.2. Это, конечно, в том случае, когда эти изменения не включены в серверную логику (в этом случае оптимальнее использование ХП и триггеров)

← →
Val © (2003-10-02 14:21) [18]

MsGuns © (02.10.03 13:42) [17]
про таймер забыли.

← →
Term (2003-10-02 14:31) [19]

> про таймер забыли

а в таймере update делать? или рефрешить?

Как писал автор BCB Unleashed, обязательно отдельные транзакции на каждую таблицу,запрос etc нужно делать только в MIDAS приложениях

Term (02.10.03 14:31) [19]
вообще-то, что хотите :) обычно рефреш.
я добавлял к пунктам из поста MsGuns.

>Val © (02.10.03 14:37) [21]
Не понимаю, как это связано с постом MsGuns ©.
Он вроде объяснял про способы подтверждения транзакций? Что-то я не понимаю куда тут можно влепить таймер.

Какой еще таймер? На хрена? А асинхронные события нельзя что-ли обрабатывать? Много чего лучше переносить на сервер - он быстрее справится, чем клиентская программа

← →
Term (2003-10-02 15:10) [25]

> Какой еще таймер? На хрена? А асинхронные события нельзя
> что-ли обрабатывать? Много чего лучше переносить на сервер
> - он быстрее справится, чем клиентская программа

можно немного подробнее про асинхронные события, чтото я в литературе не видел описания.....

POST_EVENT("name_event")
В триггерах on delete, on update, on insert
IBEVENTs

>Term (02.10.03 15:10) [25]
>можно немного подробнее про асинхронные события, чтото я в литературе не видел описания.....

Как я понял, речь идет о регистрации событий на сервере. Т.е. приложение может дать серверу знать о том, чтобы ее (прогу) он (сервер) информировал о возникновении какого-то события (например, изменения в какой-то таблице). Тогда по получении такого сообщения от сервера прога может безо всякого таймера отрефрешить соотв. НД. Подход сам по себе интересен, но злоупотребление им приведет к тому, что юзер будет не столько работать, сколько смотреть на часики на экране при достаточно активной работе с таблицей других узеров. При этом не исключено, что в данный момент он будет вводить данные в контролы, никак не связанные с рефрешируемым НД. Или, к примеру, просматривать некоторый отчет в этой же проге.
Все-таки наиболее опытные мастера (по моему мнению, ессно) рекомендуют рефреш по кнопке или по истечению заданного узером интервала (использование таймера). Но опять же все зависит от "местных" факторов: кол-ва одновременно работающих клиентов, скорости сети, объемов данных, частоты их изменяемости и т.д.

Ну-ну. А рефреш при получении сообщения от сервера нельзя ли засунуть в отдельный поток, если юзер не работает с конкретной таблицей? А если с текущей, то запрос на обновление (как делает делфи при одновременной работе с файлами проекта в среде и вне ее). И часиков видно не будет. Или накапливать сообщения, а после какого-то их числа предлагать обновить данные? IMHO, таймер применять не стоит - если есть обработка событий

Использование транзакций в IB Найти похожие ветки