iBase.ru Forum

Вот такой есть вопрос по транзакциям и не только по ним...
При работе с Paradox через BDE проблем подобного рода, конечно не было, и вообще транзакции применял только если шла запись в несколько таблиц, и нужно было гарантировать что запись прошла во все или вообще отказаться... В РСУБД (в частности FB) несколько другая идеология транзакций, поэтому сразу не очень всё понятно. Доку я конечно внимательно почитаю, просто, если не лень, кратко ответьте. Вот есть у меня DataSet (уже под FB). Отвечает за отображение данных одной из основных таблиц. Вернее в DataSet запрос SelectSQL выбирает данные не из одной этой таблицы, а из туевой хучи таблиц цепляет нужные поля. В принципе непосредственно править этот датасет вставляя данные, или удаляя. или изменяя напрямую я не хочу. Идея в том, чтобы при определённом действии с визуальным отображением DataSet'а выполнять некую процедуру, которая корректно проверит что и как сделать, и путём выполнения запроса/запросов это сделает.
1. Правильно ли я понимаю, что в этом случае мне не нужно задавать для DataSet никаких свойств кроме SelectSQL или вообще использовать в этом случае не DataSet а Query?
2. Если мой DataSet привязан к определённой транзакции, то мне обязательно другие запросы, изменяющие таблицы, из которых поля цепляются запросом, выполнять в рамках ЭТОЙ ЖЕ транзакции, или можно создать отдельную?

Извините за вопросы, просто пока читаю-читаю, и по некоторым
вопросам еще "каша в голове"... Но я исправлюсь. Со временем

Kotъ-Begemotъ писал(а): 1. Правильно ли я понимаю, что в этом случае мне не нужно задавать для DataSet никаких свойств кроме SelectSQL или вообще использовать в этом случае не DataSet а Query?
2. Если мой DataSet привязан к определённой транзакции, то мне обязательно другие запросы, изменяющие таблицы, из которых поля цепляются запросом, выполнять в рамках ЭТОЙ ЖЕ транзакции, или можно создать отдельную?

А какие компоненты пользуются?
ФИБ+ позволяет при джойнах только одну таблицу редактировать - если надо больше, то это отдельный TpFIBQuery, рефреш связанных таблиц - твои заботы
изменения по одной записи - ИМХО делаются в одной транзакции, дабы либо принять, либо откатить все
Для чения-записи в ФИБ+ возможно использовать разные транзакции, с РАЗНЫМ уровнем изолированности

Kotъ-Begemotъ писал(а):2. Если мой DataSet привязан к определённой транзакции, то мне обязательно другие запросы, изменяющие таблицы, из которых поля цепляются запросом, выполнять в рамках ЭТОЙ ЖЕ транзакции, или можно создать отдельную?

Даже желательно отдельную. Потому как Commit транзакции закроет твой датасет.

WildSery писал(а):

Kotъ-Begemotъ писал(а):2. Если мой DataSet привязан к определённой транзакции, то мне обязательно другие запросы, изменяющие таблицы, из которых поля цепляются запросом, выполнять в рамках ЭТОЙ ЖЕ транзакции, или можно создать отдельную?

Даже желательно отдельную. Потому как Commit транзакции закроет твой датасет.

Ага, то есть "наплодив" отдельных транзакций в рамках которых я планирую выполнять запросы обновляющие (добавляющие) данные я не буду выглядеть лохом? А если Dataset использует update или insert запрос, то закрытие по Commit - это я бы сказал удобно...

stix-s писал(а): А какие компоненты пользуются?
ФИБ+ позволяет при джойнах только одну таблицу редактировать - если надо больше, то это отдельный TpFIBQuery, рефреш связанных таблиц - твои заботы
изменения по одной записи - ИМХО делаются в одной транзакции, дабы либо принять, либо откатить все
Для чения-записи в ФИБ+ возможно использовать разные транзакции, с РАЗНЫМ уровнем изолированности

Да, думаю FIBPlus будет использоваться. Пока это представляется наиболее целесообразным, так как и связь с разработчиками "живая" - можно пообщаться всегда, да и компоненты временем проверены...

Kotъ-Begemotъ писал(а):А если Dataset использует update или insert запрос, то закрытие по Commit - это я бы сказал удобно...

Зачем? Он должен постоянно данные показывать. Обновил одну строку - он пусть и перечитает одну строку, а не весь датасет заново.

WildSery писал(а):

Kotъ-Begemotъ писал(а):А если Dataset использует update или insert запрос, то закрытие по Commit - это я бы сказал удобно...

Зачем? Он должен постоянно данные показывать. Обновил одну строку - он пусть и перечитает одну строку, а не весь датасет заново.

А если обновил/и другие пользователи, и неизвестно какое количество полей и записей? Работа-то многопользовательская...

Kotъ-Begemotъ писал(а):
А если обновил/и другие пользователи, и неизвестно какое количество полей и записей? Работа-то многопользовательская...

По моему этот вопрос и от этого же автора я уже видел
ответы были: (события, таймер, кнопка или их комбинации)

stix-s писал(а):По моему этот вопрос и от этого же автора я уже видел
ответы были: (события, таймер, кнопка или их комбинации)

Дык поэтому и говорю... То есть в моём случае в DataSet отображающем данные кроме SelectSQL получается другие запросы и не нужны вовсе? UpdateSQL, DeleteSQL, RefreshSQL, InsertSQL раз я буду все данные операции с помощью отдельных DataSet (Query) делать в индивидуальных "коротких" транзакциях?

Kotъ-Begemotъ писал(а): Дык поэтому и говорю... То есть в моём случае в DataSet отображающем данные кроме SelectSQL получается другие запросы и не нужны вовсе? UpdateSQL, DeleteSQL, RefreshSQL, InsertSQL раз я буду все данные операции с помощью отдельных DataSet (Query) делать в индивидуальных "коротких" транзакциях?

если только смотреть, то нет, но......., зависит от параметров транзакции

делать в индивидуальных "коротких" транзакциях?

если речь идет об обновлениях в нескольких таблицах одновременно, то я ИМХО другого выхода, как использовать TpFIBQuery я не вижу, но в отдельной, короткой пишущей транзакции
откровенно говоря, я не совсем понял вопрос

stix-s писал(а):если речь идет об обновлениях в нескольких таблицах одновременно, то я ИМХО другого выхода, как использовать TpFIBQuery я не вижу, но в отдельной, короткой пишущей транзакции
откровенно говоря, я не совсем понял вопрос

Однако ответил в нужную сторону Да, обновлять возможно придётся несколько таблиц, так как запрос с "просматривающем" DataSet тянет поля из нескольких таблиц. А датее в зависимости от действия пользователя будет обновлена основная и(или) связанные таблицы с помощью отдельных Query (upate, insert, delete) помещённых в отдельную транзакцию, сделанную максимально короткой - Старт, ExecSQL запроса, обработка ошибок, commit или возможно rollback в случае ошибок.
Про параметры транзакций пока читАю вовсю. Вроде какое-то понимание уже потихоньку приходит...

Kotъ-Begemotъ писал(а): Про параметры транзакций пока читАю вовсю. Вроде какое-то понимание уже потихоньку приходит...

загляни сюда http://forum.ibase.ru/phpBB2/viewtopic. ... 4&start=80
основная тема, может и не связана напрямую с транзакциями, но мнение Мерлина по поводу Update стоит иметь ввиду

И раз уж речь зашла: транзакции это вещь логическая. К физической схеме базы не имеющая никакого отношения. Их применение определяется бизнес-логикой.

Dimitry Sibiryakov писал(а):И раз уж речь зашла: транзакции это вещь логическая. К физической схеме базы не имеющая никакого отношения. Их применение определяется бизнес-логикой.

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

stix-s писал(а): ФИБ+ позволяет при джойнах только одну таблицу редактировать - если надо больше, то это отдельный TpFIBQuery, рефреш связанных таблиц - твои заботы

(Не)Позволяет редактировать разработчик. В ФИБ+ можно в UpdateSQL написать не классику жанра UPDATE Table ..... а EXECUTE STATEMENT (правильно..EXECUTE PROCEDURE) Procedure..., в которой делать UPDATE по нескольким таблицам, без отдельной TpFIBQuery и последующих забот с рефрешем

Monk писал(а):аписать не классику жанра UPDATE Table ..... а EXECUTE STATEMENT Procedure...

Какой ещё EXECUTE STATEMENT? Забудьте это слово.
Execute Block, или Execute Procedure.

WildSery писал(а):

Monk писал(а):аписать не классику жанра UPDATE Table ..... а EXECUTE STATEMENT Procedure...

Какой ещё EXECUTE STATEMENT? Забудьте это слово.
Execute Block, или Execute Procedure.

Да, ошибся. Незнаю вот только с какого.. переклинило. Наверное понедельник. Конечно же EXECUTE PROCEDURE

Monk писал(а): (Не)Позволяет редактировать разработчик. В ФИБ+ можно в UpdateSQL написать не классику жанра UPDATE Table ..... а EXECUTE STATEMENT (правильно..EXECUTE PROCEDURE) Procedure..., в которой делать UPDATE по нескольким таблицам, без отдельной TpFIBQuery и последующих забот с рефрешем

ИМХО EXECUTE ....... - изврат для TpFIBDataset

Забот с рефрешем собственно никаких, главное верный запрос для рефреша и своевременный его вызов

stix-s писал(а): ФИБ+ позволяет при джойнах только одну таблицу редактировать - если надо больше, то это отдельный TpFIBQuery

я и написал, что вовсе не обязательно так делать, можно и TpFibDatasetом обойтись для редактирования нескольких таблиц одновременно. Например, есть грид, куда выводится сводная, полученная из нескольких таблиц (один TpFibDataSet), при редактировании данных в ней (ну если все на Д-товарных компонентах делать), можно довольно легко сделать сохранение изменения информации в редактируемой таблице пользуясь только одним компонентом TpFibDataSet, вынеся логику на сервер в процедуру.

stix-s писал(а): ИМХО EXECUTE ....... - изврат для TpFIBDataset

А в чем изврат?