Форум: "Прочее";
Текущий архив: 2011.12.04;
Скачать: [xml.tar.bz2];
ВнизКомпоненты DB. Найти похожие ветки
← →
Leon-Z © (2011-08-08 17:27) [0]А Вы используете компоненты DB ? те. DBEdit, DBComboBox, ... для вставки
и редактирования записей DataSet"a ???
Вообщем вопрос такой: Что лучше - использовать DB компоненты или
обойтись обычными TEdit, TComboBox, ... и просто дописать кусочек кода,
который например при редактировании записи будет извлекать данные из
DataSet"a и подставлять в эти компоненты ?
← →
Kerk © (2011-08-08 17:29) [1]В общем случае, меньше кода - меньше ошибок.
А частные случаи бывают разными.
← →
OW © (2011-08-08 17:31) [2]если есть время и опыт - пишите
сам пробовал - очень много возни, пожалел уже 100 раз. Лучше бы DB взял.
DB + CashedUpdates - очень гибко получается.
← →
SegeyIT (2011-08-08 17:36) [3]Зависит от задач.
← →
Dennis I. Komarov © (2011-08-08 17:36) [4]Зависит от задачи. А вообще, не люблю DB в GUI, да и пользователю незачем, за редким исключением...
← →
Leon-Z © (2011-08-08 17:37) [5]А как же быть если DataSet состоит из 2-х и более таблиц ???
Например если Вы используете Query ???
В этом случае через DB компоненты не отредактируешь или
не обновишь набор. Как тогда быть ?
← →
OW © (2011-08-08 17:38) [6]updateSQL есть у многих компонентов, вот там и прописываю что надо сделать
← →
oldman © (2011-08-08 17:57) [7]
> для вставки
> и редактирования записей DataSet"a ???
Пользуйся чем хочешь, хоть TEdit, хоть DBEdit.
Желательно все делать в отдельном модальном окне и менять датасет при нажатии на кнопку.
При таком подходе компоненты не играют роли, задача проверки ввода и контроля изменений упрощается.
← →
Leon-Z © (2011-08-08 18:17) [8]
> Желательно все делать в отдельном модальном окне и менять
> датасет при нажатии на кнопку.
А если я располагаю компоненты под гридом на панели ?
← →
Ega23 © (2011-08-08 20:28) [9]TDBComboBox использовал, на нём Maset-detail хорошо получается.
TDBTreeView, TDBImageList - это уже сам писал
Сейчас вообще ничего не использую, задачи не те.
← →
asail © (2011-08-08 20:37) [10]
> Kerk © (08.08.11 17:29) [1]
> В общем случае, меньше кода - меньше ошибок.
Так то оно, конечно, так. Но, например, необходимость держать открытый коннект к БД и открытую же транзакцию напрягает. Много неприятностей на этом деле имели (особливо с БДЕ)... Лично я предпочитаю сливать данные в какой нибудь TClientDataSet и уже к ним подключать DBAware компоненты (гриды там всякие). По завершению работы, раскидывать все обратно в БД одной короткой транзакцией. К отчетам это тоже относится.
Правда, весь мой реальный опыт (хоть и весьма долгий) относится к Interbase. С другими БД, может, и по-другому лучше работать.
← →
Ega23 © (2011-08-08 20:42) [11]
> Но, например, необходимость держать открытый коннект к
> БД и открытую же транзакцию напрягает.
Ээээ... Чем напрягает?
← →
asail © (2011-08-08 20:54) [12]
> Ega23 © (08.08.11 20:42) [11]
Ну, например, возникновением большой кучи мусора в БД. Ибо интербэйс есть версионная БД, и все конкурирующие транзакции (коих может быть не мало) активно начинают создавать версии одних и тех же записей, видя, что одна из транзакций держит таблицу...
Еще, например, есть некий сервис, который переодически делает бэкап/рестор БД. И, соответсвенно, отключает все имеющиеся коннекты. Ну да, посылает там запросы клиентам на отключение, ждет какое-то время, пока они нормально отрубятся... Но, они может и не отрубятся никогда... Зашел юзверь в грид, ввел одну буковку в поле и ушел обедать до вечера. А табличка то в dsEdit или в dsInsert висит... Хорошо хоть, что IB блокировки не вешает...
← →
Inovet © (2011-08-08 21:03) [13]> [12] asail © (08.08.11 20:54)
> активно начинают создавать версии одних и тех же записей,
> видя, что одна из транзакций держит таблицу...
Долгая читающая и короткая пишущая. И о коннекте не ответил.
← →
Leon-Z © (2011-08-08 21:21) [14]Я таки и не понял. Юзать DB компоненты или нет ?
Неважно какая БД - серверная или локальная, Paradox, MsAccess, InterBase...
Вопрос об удобстве и понятности интерфейса !!!
Ну и конечно же желательно, чтобы выбранный вариант позволял меньше
кодить, а соотв. соглашусь с постом выше - меньше делать ошибок.
← →
Kerk © (2011-08-08 21:23) [15]А причем тут удобство интерфейса?
← →
Ega23 © (2011-08-08 21:44) [16]
> Ну, например, возникновением большой кучи мусора в БД. Ибо
> интербэйс есть версионная БД, и все конкурирующие транзакции
> (коих может быть не мало) активно начинают создавать версии
> одних и тех же записей, видя, что одна из транзакций держит
> таблицу...
А зачем такой изврат?
> Зашел юзверь в грид, ввел одну буковку в поле и ушел обедать
> до вечера. А табличка то в dsEdit или в dsInsert висит..
Не, ну если с ней как с Парадоксом работать, то да. Подход у тебя в целом неверный.
← →
Ega23 © (2011-08-08 21:45) [17]
> Вопрос об удобстве и понятности интерфейса !!!
Как ты визуально TDBEdit отличишь от TEdit? TDBComboBox от TComboBox?
← →
Leon-Z © (2011-08-08 21:47) [18]
> Ega23 © (08.08.11 21:45) [17]
> > Вопрос об удобстве и понятности интерфейса !!!Как ты визуально
> TDBEdit отличишь от TEdit? TDBComboBox от TComboBox?
Отличу !!!!!!!!
Как - посмотрю что происходит с Edit"ом при переходе из dsBrowse в dsInsert.
← →
Inovet © (2011-08-08 21:49) [19]> [18] Leon-Z © (08.08.11 21:47)
> Отличу !!!!!!!!
Вопрос о пользователе.
← →
DVM © (2011-08-08 22:16) [20]
> Leon-Z © (08.08.11 21:21) [14]
> Я таки и не понял. Юзать DB компоненты или нет ?
> Ну и конечно же желательно, чтобы выбранный вариант позволял
> меньше
> кодить, а соотв. соглашусь с постом выше - меньше делать
> ошибок.
используй
← →
Игорь Шевченко © (2011-08-08 22:39) [21]asail © (08.08.11 20:54) [12]
> Ибо интербэйс есть версионная БД, и все конкурирующие транзакции
> (коих может быть не мало) активно начинают создавать версии
> одних и тех же записей, видя, что одна из транзакций держит
> таблицу...
Э...я что-то пропустил ? Мне казалось, что Insert не приводит к "держанию таблицы", а все действия по модификации возникают во время Post.
← →
asail © (2011-08-08 23:32) [22]
> Inovet © (08.08.11 21:03) [13]
> Долгая читающая и короткая пишущая.
1. БДЕ не знает, что такая "читающая". Он с интербэйсом только один уровень изоляции транзакций знает - Read Commited.
2. А как читающая, если там грид и TDBEdit например.
> И о коннекте не ответил
Да Бог с ним, с коннектом. Транзакция висит - тут засада.
> Ega23 © (08.08.11 21:44) [16]
> А зачем такой изврат?
Это ты не меня спрашивай, а Борланд. :) Хотя, свом плюсы в версионности свои есть...
> Подход у тебя в целом неверный
Я, как раз, наоборот говорю. Лучше локально с данными работать... Имхо.
← →
asail © (2011-08-08 23:38) [23]
> Игорь Шевченко © (08.08.11 22:39) [21]
И да, и нет. Интербэйс таблицы не "держит". Т.е. не блокирует. Но, вот представь, ты редактируешь несколько записей в таблице, делая Post. Пока транзакция не будет закомитенна, все другие транзакции будут считать эти записи "занятыми" и создавать свои собственные версии записей... Что сильно грузит БД "мусором". Хотя, в том, что данные в БД физически попадают только после Post, ты прав.
← →
Jeer © (2011-08-08 23:47) [24]
> А Вы используете компоненты DB
Стандартные - не использую.
← →
Игорь Шевченко © (2011-08-08 23:55) [25]asail © (08.08.11 23:38) [23]
Я сильно извиняюсь, но Post он обычно по кнопке OK происходит, а не в раздумьях над открытой маской ввода. То есть, относительно быстро. И если Post не закончился с ошибкой, то обычно после него выполняется commit, ну или rollback в случае если с ошибкой.
← →
asail © (2011-08-09 00:13) [26]
> Игорь Шевченко © (08.08.11 23:55) [25]
> И если Post не закончился с ошибкой, то обычно после него
> выполняется commit
Чой-то? Commit сам по себе обычно только при закрытии датасета/ов происходит. А если его ручками вызывать, то все датасеты позакрываются, и их открывать опять надо. БДЕ, правда, это вроде как сам делает...
← →
Игорь Шевченко © (2011-08-09 00:25) [27]
> Чой-то? Commit сам по себе обычно только при закрытии датасета/ов
> происходит. А если его ручками вызывать, то все датасеты
> позакрываются, и их открывать опять надо.
Это у вас консерватория неправильная.
← →
Ega23 © (2011-08-09 01:02) [28]
> Чой-то? Commit сам по себе обычно только при закрытии датасета/ов
> происходит. А если его ручками вызывать, то все датасеты
> позакрываются, и их открывать опять надо.
Есть читающая транзакция, и есть пишущая. В читающей - таки да, Read Commited. Но пишущая-то у тебя отрабатывает сразу, либо Commit либо Rollback
> Это у вас консерватория неправильная.
+1
← →
asail © (2011-08-09 01:51) [29]
> Игорь Шевченко © (09.08.11 00:25) [27]
> Это у вас консерватория неправильная.
Я консерваторий не заканчивал. :)
> Ega23 © (09.08.11 01:02) [28]
Еще раз. В БДЕ нет "читающих" транзакций. Они все пишущие. Ну низя там выставить параметры read или tablestability...
Да и в IBExpress, для грида в котором юзверь имеет право менять данные, транзакцию только для чтения использовать низя. А все другие варианты могут приводить к обрастанию БД "мусорными" версиями записей.
Как пример, возьми TIBDataset, TDatasource и TDBGrid. Подключи все это друг к дружке и к TIBTransaction. Начни транзакцию (явно или нет) и откорой датасет. Начни редактировать данные в гриде (хотя бы несколько записей). Теперь запусти еще одно приложение, которое будет тупо спамить те же записи апдейтами... До тех пор, пока ты не вызовешь Commit в первом приложении выглядеть все будет замечательно. Вот только размер БД будет увеличиваться и увеличиваться... Ну и при коммите, ясень пень, ошибку получим, дескать данные изменены другим пользователем. Ну да фиг с ней с ошибкой... Главное, что во время редактирования грида и до коммита, база будет разбухать, почем зря.
Согласен, это особенности интербейса, но тем не менее... Кстати, на ibase.ru все пордробненько изложенно. Например тута:
http://www.ibase.ru/devinfo/ibx.htm (смотри абзац начинающийся с "Транзакции должны быть максимально короткими").
И главное, свои то предложения какие будут?
← →
Inovet © (2011-08-09 02:39) [30]> [22] asail © (08.08.11 23:32)
> 1. БДЕ не знает, что такая "читающая". Он с интербэйсом
> только один уровень изоляции транзакций знает - Read Commited.
> 2. А как читающая, если там грид и TDBEdit например.
1. Надо IBX пользовать, а в FIB такое встроено в сами компонеты, не пользовал.
2. Ну и какая разница чем отображать-редактировать.
Транзакции только правильно настроить надо для типового случая.
← →
Ega23 © (2011-08-09 08:02) [31]
> Транзакции должны быть максимально короткими
Вот это правильно, дело на ibase говорят.
> И главное, свои то предложения какие будут?
Нафига в гриде редактировать, раз получаешь столько много геморроя?
← →
Кщд (2011-08-09 08:49) [32]>asail © (09.08.11 01:51) [29]
>В БДЕ нет "читающих" транзакций.
Под "читающей" понимается не уровень изоляции транзакции, а лишь то, что в её контексте не происходит dml-операций - только select.
← →
Anatoly Podgoretsky © (2011-08-09 09:02) [33]> Игорь Шевченко (08.08.2011 23:55:25) [25]
Ты не учитываешь dbAwarе поколение, где трансакция начинаяся с команды Edit
или ее эквивалента, особенно наглядно это в БДЕ
← →
Anatoly Podgoretsky © (2011-08-09 09:07) [34]> Ega23 (09.08.2011 08:02:31) [31]
Грид/форма какая разница, редактировать надо в TEdit - то есть работать с
запросами, а не методами dbAware компонент. Тогда всего два или один
коротких запроса SELECT и INSERT/UPDATE.
Конечно мозолей на пальцах будет больше, но и управления больше.
← →
Ega23 © (2011-08-09 10:31) [35]
> редактировать надо в TEdit - то есть работать с
> запросами, а не методами dbAware компонент
Я в курсе. Если чё.
← →
Игорь Шевченко © (2011-08-09 11:39) [36]Anatoly Podgoretsky © (09.08.11 09:07) [34]
> Грид/форма какая разница, редактировать надо в TEdit - то
> есть работать с
> запросами, а не методами dbAware компонент. Тогда всего
> два или один
> коротких запроса SELECT и INSERT/UPDATE.
Ох уж эти сказочники. DBAware-компоненты сами по себе никаких запросов не выдают.
← →
asail © (2011-08-09 12:52) [37]
> Ega23 © (09.08.11 08:02) [31]
> Нафига в гриде редактировать, раз получаешь столько много
> геморроя?
Так а я то про что? Я ж и говорю, нефиг использовать гриды напрямую завязанные на датасеты, подключенные к БД. Если грид необходим, то я предпочитаю залить данные в какой нибудь ClientDataSet и уже его подключать к гриду. При этом нет ни одной открытой транзакции в БД. Алгоритм примерно такой:
1. StartTransaction (read only по возможности)
2. Выбераем все необходимые данные из БД и заливаем в ClientDataSet/ы.
3. Commit.
4. Делаем с данными в ClientDataSet че хотим, хоть с гридами, хоть с чем...
5. StartTransaction (пишущая).
6. Сливаем измененные данные из ClientDataSet/ов обратно в БД.
7. Commit.
Таким образом избавляемся от долгих транзакций и от гемороя, с ним связанным. Правда, кода получается больше благодаря пунктам 2 и 6.
З.Ы. Вместо ClientDataSet может использоваться свой набор классов, описывающий данные из БД, но тут возникают уже сложности с представлением их во всяких там гридах и TDBLookup"ах. Можно, конечно, и свой грид написать, работающий, например, с датасетами на основе, скажем, TList. Но нафига? ClientDataSet вполне достаточен в большинстве случаев, имхо.
Критикуйте...
← →
asail © (2011-08-09 12:56) [38]
> Inovet © (09.08.11 02:39) [30]
> Надо IBX пользовать
Пользуем. При работе с DBaware проблемы теже. При отображении/редактировании данных в гриде, датасет должен быть открыт и транзакция висеть открытой все то время, что пользователь работает с гридом. Если грид только для чтения, то да можно использовать Read only table stability транзакции. Они стартуют уже закомиченными и на работу конкурирующих транзакций влияния не оказывают.
← →
Ega23 © (2011-08-09 13:02) [39]
> Критикуйте...
Зачем пункты 1..3?
Запуск приложения - StartReadonlyTransaction
Окончание приложения - Commit
Зачем в CDS переливать? Дабл-кликнул на гриде - открыл модальную форму с данными (причём спецом их из БД перечитал, мало ли кто там чего направил), отредактировал как надо, нажал OK, открыл пишущую транзакцию, залил, закоммитил, перечитал данные в грид.
Вариант с модальной формой может быть заменён на альтернативный, сути дела это не меняет.
← →
Игорь Шевченко © (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 © (2011-08-10 16:34) [64]
> asail © (10.08.11 16:32) [63]
Там беда в том, что первая транзакция, хоть и не создает новых версий, но являесь старейшей заинтересованной транзакцией, не дает работать сборщику мусора. Иначе, третья транзакция подчистила бы версию второй...
Вот тут еще подробней:
http://ibase.ru/devinfo/oitoat.htm
← →
DiamondShark © (2011-08-10 16:44) [65]
> Игорь Шевченко © (09.08.11 17:51) [54]
> вот смотри - есть таблица, есть ее отображение в гриде DataSource,
> TQuery(SELECT field1, field2, ... FROM foo WHERE field1
> = bar1, etc)
> есть UpdateSQL для этого Query (INSERT, UPDATE, DELETE)
Не знаю, как там в интербейсе и прочих версионниках, а на МССКЛ (и похожих) имеете все шансы нарваться на описанный мной вариант.
← →
Игорь Шевченко © (2011-08-10 17:25) [66]DiamondShark © (10.08.11 16:44) [65]
В вашей ситуации еще есть слой ODBC со своими настройками, насколько я понял.
asail © (10.08.11 16:32) [63]
Я больше склонен к ответу Anatoly Podgoretsky © (10.08.11 15:51) [62]
Однако пример был бы крайне желателен. То есть, по твоему получается, что если есть хотя бы один "открытый" SELECT, то все изменения одной и той же записи будут приводить к созданию новых версий ?
← →
asail © (2011-08-10 18:26) [67]
> Игорь Шевченко © (10.08.11 17:25) [66]
> То есть, по твоему получается, что если есть хотя бы один
> "открытый" SELECT, то все изменения одной и той же записи
> будут приводить к созданию новых версий ?
Не совсем. Все изменения одной и той же записи в любом случае будут приводить к созданию новых версий, даже, без "открытых" SELECT"ов. Но, если нет открытого селекта (читай еще одной заинтересованной транзакции), то каждая следующая транзакция будет подчищать "мусор" от предыдущих. А вот если есть, то "мусор" будет копиться, что в конечном итоге может привести к резкому падению производительности сервера... С чем я уже неоднократно сталкивался. :(
Именно поэтому и стараюсь свести продолжительность каждой отдельной транзакции к минимуму (на сколько это возможно, конечно).
← →
Anatoly Podgoretsky © (2011-08-10 18:59) [68]> Игорь Шевченко (10.08.2011 17:25:06) [66]
Это лучше выяснять на ibase.ru - там сидят спецы.
← →
Игорь Шевченко © (2011-08-10 19:11) [69]asail © (10.08.11 18:26) [67]
Я же говорил, что консерватория неправильная :)
← →
asail © (2011-08-10 19:15) [70]
> Игорь Шевченко © (10.08.11 19:11) [69]
Не понял? Это про версионные БД вообще и про IB/FireBird в частности?
Если да, то утверждение спорное. Бо, есть свои как плюсы так и минусы в сей архитектуре...
← →
Игорь Шевченко © (2011-08-10 19:50) [71]asail © (10.08.11 19:15) [70]
> про IB/FireBird в частности?
Про него, естественно. Oracle, как известно, тоже можно отнести с некоторой натяжкой к версионникам, но такого, чтобы один читающий сеанс вызывал порождение массы закоммиченных версий одной и тоже записи там нету.
Про IB/FireBird благодарю за ссылки, освежил в памяти. В частности про то, что каждая транзакция подчищает версии записи, а не только sweeper.
← →
asail © (2011-08-10 20:37) [72]
> Игорь Шевченко © (10.08.11 19:50) [71]
Мне, увы, трудно спорить по данному вопросу, ибо реального опыта с другими БД не имею.
А насчет читающих сеансов, порождающих массы версий, так это решается с помощью простых действий. Например, читающая транзакция с параметрами read и read_commited не будет вызывать такого эффекта, ибо стартует сразу в статусе Commited. Вот только БДЕ таких типов транзакций не знает... А с IBX вполне можно разрулить.
← →
Ega23 © (2011-08-10 20:38) [73]
> Игорь Шевченко © (10.08.11 19:50) [71]
>
> > про IB/FireBird в частности?
> Про него, естественно.
Дык в TIBTransaction реализовано, чтение это или запись.
IBExpert ведь как-то работает и не жужжит...
Страницы: 1 2 вся ветка
Форум: "Прочее";
Текущий архив: 2011.12.04;
Скачать: [xml.tar.bz2];
Память: 0.69 MB
Время: 0.005 c