Компоненты DB.

← →
Игорь Шевченко © (2011-08-09 13:11) [40]

asail © (09.08.11 12:52) [37]

> Критикуйте...

Когда коту нечего делать...

Я честно не понимаю, зачем выполнять лишнюю работу. Авторы компонент доступа к Interbase рекомендуют ?

← →
Sergey13 © (2011-08-09 13:25) [41]

> [39] Ega23 © (09.08.11 13:02)
> отредактировал как надо, нажал OK, открыл пишущую транзакцию,
> залил, закоммитил, перечитал данные в грид.

Чем это лучше, чем использование методов датасета? Даже перечитывать ничего не надо, и соответственно позиционироваться на старое место. Не скажу за все компоненты, но вот помнится DOA даже текущую запись перед редактированием перечитывал с блокировкой сама.

← →
asail © (2011-08-09 13:59) [42]

> Ega23 © (09.08.11 13:02) [39]

> Дабл-кликнул на гриде - открыл модальную форму с данными

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

← →
Ega23 © (2011-08-09 14:04) [43]

> Во-первых, как я уже говорил, БДЕ реад онли транзакций не
> знает.

Мне просто интересно, а как же я раньше BDE пользовался?

> Причем, многие гриды позволяют это делать весьма и весьма
> наглядно и удобно, напрмер, грид из DevExpress.

В гриде висит далеко не вся информация по сущности.
Конечно, если запрос select * from xxx, то да. Но как правило это довольно сложная выборка с различными объединениями со справками и т.п. Это первое.
Второе: пользователь может сам настроить, что ему грид показывает, а что - нет и в каком порядке (пользователю всё-таки виднее).
Вот, собственно, и всё.

← →
Игорь Шевченко © (2011-08-09 14:04) [44]

> Во-вторых, нафига еще одна форма, когда данные можно напрямую
> в гриде править?

в гриде нету кнопки OK

← →
DiamondShark © (2011-08-09 14:05) [45]

С BDE была однажды веселуха.

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

Попробовали monkey-test, условия возникновения зависания какие-то мутные, трудноспроизводимые. Но точно выяснилось, что зависание происходит при отрытом гриде и исполнении апдейтов в некоем TQuery.

Прграмма работала через BDE поверх ODBC. Включили трассировку ODBC и офигели.
BDE при подключении запрашивает кучу всяких параметров от драйвера ODBC, в том числе, такой интересный параметр, как максимальное число одновременно открытых statements. Нам "повезло", что наш драйвер (MSSQL 7.0) возвращал для этого параметра 1. Что это значит? А то, что открыть на одном коннекте два курсора, или выполнить при уже открытом курсоре какой-нибудь другой оператор невозможно.
Но BDE ведь позволяет открывать сколько угодно датасетов! Как? А очень просто. Во-первых, если навигация по датасету (типа, MoveNext, MoveLast) дошла до конца курсора, то BDE закрывает ODBC statement и дальше пользуется локальным кэшем. Если же так случилось, что открытый датасет не выкачал все данные из открытого курсора, то BDE что делать? Да открыть второй ODBC-коннект же!
Теперь понятно, почему происходили зависания.
У нас есть открытый датасет, N записей которого показаны в гриде. За этим датасетом висит открытый ODBC statement с уровнем изоляции READ COMMITTED.
Теперь мы пытаемся выполнить какой-то запрос, например, UPDATE, или вызвать хранимую процедуру. BDE не может открыть второй ODBC statement, создаёт новое ODBC подключение и уже в нём выполняет запрос.
Выполняемый запрос каким-либо образом (прямой UPDATE, в процедуре, или в триггере) пытается модифицировать данные, используемые открытым курсором, натыкается на SHARED LOCK и честно остаётся ждать, когда он будет отпущен. Так как всё это происходит из одного и того же потока, то шансов дождаться этого, понятное дело, нет никаких.

Это называется сокрытая сложность.

← →
DiamondShark © (2011-08-09 14:07) [46]

Почитал коменты.

Как же, всё-таки, хорошо, что есть ADO.NET и Windows Forms.

← →
Anatoly Podgoretsky © (2011-08-09 14:32) [47]

> Игорь Шевченко (09.08.2011 14:04:44) [44]

Именно и это страшно

← →
boriskb © (2011-08-09 14:36) [48]

> DiamondShark © (09.08.11 14:05) [45]

Вот такие моменты мне больше всего радости доставляли. К несчастью работодателя
Не сами затыки конечно, а их нахождение :)

А когда все с лёту гладко идёт... это конечно радует, но не 10 лет подряд ...
Это как на конвейре стоять.

← →
Dennis I. Komarov © (2011-08-09 14:49) [49]

1. Грид - зло! (Исключения есть)
2. Логика работы с БД должна быть скрыта от пользователя (из GUI). (опять же есть)
3. SQL спасет всех

← →
Sergey13 © (2011-08-09 16:41) [50]

> [49] Dennis I. Komarov © (09.08.11 14:49)
1. Работать с таблицей как с таблицей зло? Что тогда добро?
2. ИМХО красивый набор слов.
3. От чего?

← →
asail © (2011-08-09 17:01) [51]

> Игорь Шевченко © (09.08.11 14:04) [44]

> в гриде нету кнопки OK

Она вполне так может быть рядом/сверху/снизу... Более того, туды можно даже кнопку Cancel нарисовать! :)

> Ega23 © (09.08.11 14:04) [43]

> > Во-первых, как я уже говорил, БДЕ реад онли транзакций
> не
> > знает.
>
> Мне просто интересно, а как же я раньше BDE пользовался?

Вот так и пользовался, без реадонли транзакций (мы же все еще про IB говорим?)...
Кстати, я им и сейчас пользуюсь... :(

> DiamondShark © (09.08.11 14:05) [45]

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

← →
Ega23 © (2011-08-09 17:17) [52]

> 1. Работать с таблицей как с таблицей зло? Что тогда добро?

Работать с таблицей как с таблицей - не зло. Зло - держать таблицу залоченной.

← →
asail © (2011-08-09 17:28) [53]

> Ega23 © (09.08.11 17:17) [52]

> Зло - держать таблицу залоченной

+100500

← →
Игорь Шевченко © (2011-08-09 17:51) [54]

asail © (09.08.11 17:01) [51]

И реактор на субтепловых нейтронах приделать. Вопрос - зачем ?

> Кстати, я им и сейчас пользуюсь... :(

вот смотри - есть таблица, есть ее отображение в гриде DataSource, TQuery(SELECT field1, field2, ... FROM foo WHERE field1 = bar1, etc)

есть UpdateSQL для этого Query (INSERT, UPDATE, DELETE)

есть форма редактирования данных этого запроса, c data-aware контролами, по кнопке OK вызывается Post и ApplyUpdates, если все хорошо, то Commit, если все плохо, то Rollback.

Вопрос - в какой момент плодятся версии записей при таком подходе ?

← →
asail © (2011-08-09 21:35) [55]

> Игорь Шевченко © (09.08.11 17:51) [54]

Насколько я помню, в момент открытия TQuery. Ибо, даже SELECT в контексте пишущей транзакции (а БДЕ других и не знает), пометит прочитанные записи своим transaction id. Соответственно, все другие транзакции будут создавать свои версии, пока не будет Commit первой. А коммита не будет, пока не закроешь этот TQuery. Кстати, у БДЕшного TQuery, вроде нет UpdateSQL (в Дельфи 6, по крайней мере).

> есть форма редактирования данных этого запроса

Тогда все зашибись будет, при условии, что не БДЕ, и тот TQuery на гриде будет висеть на реадонли TTransaction, которая уже стартует закомиченной... Тогда в форме редактирования, должен быть уже другой TQuery, подключенный к другому TTransaction (не readonly).

Это то, что я помню по теории... Поправь, если я не прав.

Игорь, возможно, ты меня не совсем правильно понял. Я не утверждаю, что DBaware-компоненты есть вселенское зло. Я только говорю, что пользоваться ими надо осторожно. Учитывая всякие нюансы, типа как в [45].
И как я уже писал, сам я их использую постоянно.

← →
Ega23 © (2011-08-09 21:52) [56]

> Насколько я помню, в момент открытия TQuery. Ибо, даже SELECT
> в контексте пишущей транзакции (а БДЕ других и не знает),
> пометит прочитанные записи своим transaction id. Соответственно,
> все другие транзакции будут создавать свои версии, пока
> не будет Commit первой. А коммита не будет, пока не закроешь
> этот TQuery. Кстати, у БДЕшного TQuery, вроде нет UpdateSQL
> (в Дельфи 6, по крайней мере).

Ах вон оно что. Я то сразу и не понял...
Я вот дико извиняюсь, но ЕМНИП даже в Delphi 5 наряду с вкладкой BDE была вкладка IB. Где были всякие TIBDataBase, TIBTransaction, TIBDataSet etc. И отдельная ADO.
Нафига к IB стучаться через BDE, если есть нативные компоненты? На ректальную тонзиллотомию похоже..

← →
Игорь Шевченко © (2011-08-09 22:16) [57]

asail © (09.08.11 21:35) [55]

> Кстати, у БДЕшного TQuery, вроде нет UpdateSQL (в Дельфи
> 6, по крайней мере).

Кстати есть

> пометит прочитанные записи своим transaction id. Соответственно,
> все другие транзакции будут создавать свои версии, пока
> не будет Commit первой. А коммита не будет, пока не закроешь
> этот TQuery.

Э...у меня TQuery выполнил SELECT из таблицы с дофигища зиллионов записей. Ты хочешь сказать, что любая транзакция другая будет создавать свои версии для КАЖДОЙ записи из этой таблицы, только потому, что ее кто-то прочитал ?
Не верится.

Ссылка на официальную документацию приветствуется.

Ega23 © (09.08.11 21:52) [56]

> Нафига к IB стучаться через BDE, если есть нативные компоненты?
> На ректальную тонзиллотомию похоже..

Видишь ли, Олег, тому может быть много причин. Например, BDE появился раньше, чем IBX, например IBX в каких-то версиях был глючным, а BDE - нет.
Поэтому ты не торопись диагностировать.

← →
Dennis I. Komarov © (2011-08-10 11:52) [58]

> На ректальную тонзиллотомию похоже..

Иногда я очень сомневаюсь в правдивости твоего места работы :)

← →
asail © (2011-08-10 14:11) [59]

> Игорь Шевченко © (09.08.11 22:16) [57]

> Кстати есть

Я понял. Ты про UpdateObject, видимо. Ну да, есть. Только он не шибко помогает. Ибо:

> Ссылка на официальную документацию приветствуется

http://ibase.ru/devinfo/ibtrans.htm (может, и не совсем официальная, но я причин не доверять не вижу).
Читаем главу "Предупреждение проблем".
Цитирую:
Чем дольше работает транзакция (кроме rc read only, см. выше), тем больше версий она удерживает, т.к. сервер считает, что версии могут этой транзакции понадобиться. Транзакция, вообще-то, может вообще ничего не делать (ни читать ни писать), т.к. для удержания версий достаточно одного ее старта...

← →
Игорь Шевченко © (2011-08-10 15:28) [60]

> Чем дольше работает транзакция (кроме rc read only, см.
> выше), тем больше версий она удерживает

Вот давай рассмотрим пример: Я сделал SELECT из таблицы.
Кто-то второй изменил запись, которая в этот SELECT попадает, сказал COMMIT, в базе появилось две версии, одна для SELECT, вторая закомиченная после изменения. Верно ?
Кто-то третий изменил ту же запись, что и второй, тоже сказал COMMIT.
Сколько версий одной записи будет ? Две или три ?

← →
Anatoly Podgoretsky © (2011-08-10 15:41) [61]

> Игорь Шевченко (10.08.2011 15:28:00) [60]

Одна

← →
Anatoly Podgoretsky © (2011-08-10 15:51) [62]

> Anatoly Podgoretsky (10.08.2011 15:41:01) [61]

Вообще то две, старая для select и последнея измененая.

← →
asail © (2011-08-10 16:32) [63]

> Игорь Шевченко © (10.08.11 15:28) [60]

Получается, что 2. Обе закомиченные от 2-ой и 3-ей транзакций. От первой, вроде, не будет ибо данные то не менялись...
Вот тут тоже более менее подробно расписанно.
http://ibase.ru/devinfo/mga.htm
Оттуда:
Сколько версий? А сколько надо? Собственно, при каждом обновлении записи создается новая версия. Значит, committed-версий у одной записи может быть сколько угодно (я видел примерно 800 тысяч версий у одной записи). А вот не-committed версия может существовать только одна.

> asail © (10.08.11 16:32) [63]

Там беда в том, что первая транзакция, хоть и не создает новых версий, но являесь старейшей заинтересованной транзакцией, не дает работать сборщику мусора. Иначе, третья транзакция подчистила бы версию второй...
Вот тут еще подробней:
http://ibase.ru/devinfo/oitoat.htm

> Игорь Шевченко © (09.08.11 17:51) [54]

> вот смотри - есть таблица, есть ее отображение в гриде DataSource,
> TQuery(SELECT field1, field2, ... FROM foo WHERE field1
> = bar1, etc)
> есть UpdateSQL для этого Query (INSERT, UPDATE, DELETE)

Не знаю, как там в интербейсе и прочих версионниках, а на МССКЛ (и похожих) имеете все шансы нарваться на описанный мной вариант.

DiamondShark © (10.08.11 16:44) [65]

В вашей ситуации еще есть слой ODBC со своими настройками, насколько я понял.

asail © (10.08.11 16:32) [63]

Я больше склонен к ответу Anatoly Podgoretsky © (10.08.11 15:51) [62]

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

> Игорь Шевченко © (10.08.11 17:25) [66]

> То есть, по твоему получается, что если есть хотя бы один
> "открытый" SELECT, то все изменения одной и той же записи
> будут приводить к созданию новых версий ?

Не совсем. Все изменения одной и той же записи в любом случае будут приводить к созданию новых версий, даже, без "открытых" SELECT"ов. Но, если нет открытого селекта (читай еще одной заинтересованной транзакции), то каждая следующая транзакция будет подчищать "мусор" от предыдущих. А вот если есть, то "мусор" будет копиться, что в конечном итоге может привести к резкому падению производительности сервера... С чем я уже неоднократно сталкивался. :(
Именно поэтому и стараюсь свести продолжительность каждой отдельной транзакции к минимуму (на сколько это возможно, конечно).

> Игорь Шевченко (10.08.2011 17:25:06) [66]

Это лучше выяснять на ibase.ru - там сидят спецы.

> Игорь Шевченко © (10.08.11 19:11) [69]

Не понял? Это про версионные БД вообще и про IB/FireBird в частности?
Если да, то утверждение спорное. Бо, есть свои как плюсы так и минусы в сей архитектуре...

asail © (10.08.11 19:15) [70]

> про IB/FireBird в частности?

Про него, естественно. Oracle, как известно, тоже можно отнести с некоторой натяжкой к версионникам, но такого, чтобы один читающий сеанс вызывал порождение массы закоммиченных версий одной и тоже записи там нету.

Про IB/FireBird благодарю за ссылки, освежил в памяти. В частности про то, что каждая транзакция подчищает версии записи, а не только sweeper.

> Игорь Шевченко © (10.08.11 19:50) [71]

Мне, увы, трудно спорить по данному вопросу, ибо реального опыта с другими БД не имею.

А насчет читающих сеансов, порождающих массы версий, так это решается с помощью простых действий. Например, читающая транзакция с параметрами read и read_commited не будет вызывать такого эффекта, ибо стартует сразу в статусе Commited. Вот только БДЕ таких типов транзакций не знает... А с IBX вполне можно разрулить.

> Игорь Шевченко © (10.08.11 19:50) [71]
>
> > про IB/FireBird в частности?
> Про него, естественно.

Дык в TIBTransaction реализовано, чтение это или запись.
IBExpert ведь как-то работает и не жужжит...

Компоненты DB. Найти похожие ветки