Компоненты 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

> Игорь Шевченко © (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 (смотри абзац начинающийся с "Транзакции должны быть максимально короткими").

И главное, свои то предложения какие будут?

> [22] asail © (08.08.11 23:32)
> 1. БДЕ не знает, что такая "читающая". Он с интербэйсом
> только один уровень изоляции транзакций знает - Read Commited.
> 2. А как читающая, если там грид и TDBEdit например.

1. Надо IBX пользовать, а в FIB такое встроено в сами компонеты, не пользовал.
2. Ну и какая разница чем отображать-редактировать.

Транзакции только правильно настроить надо для типового случая.

> Транзакции должны быть максимально короткими

Вот это правильно, дело на ibase говорят.

> И главное, свои то предложения какие будут?

Нафига в гриде редактировать, раз получаешь столько много геморроя?

← →
Кщд (2011-08-09 08:49) [32]

>asail © (09.08.11 01:51) [29]
>В БДЕ нет "читающих" транзакций.
Под "читающей" понимается не уровень изоляции транзакции, а лишь то, что в её контексте не происходит dml-операций - только select.

> Игорь Шевченко (08.08.2011 23:55:25) [25]

Ты не учитываешь dbAwarе поколение, где трансакция начинаяся с команды Edit
или ее эквивалента, особенно наглядно это в БДЕ

> Ega23 (09.08.2011 08:02:31) [31]

Грид/форма какая разница, редактировать надо в TEdit - то есть работать с
запросами, а не методами dbAware компонент. Тогда всего два или один
коротких запроса SELECT и INSERT/UPDATE.
Конечно мозолей на пальцах будет больше, но и управления больше.

> редактировать надо в TEdit - то есть работать с
> запросами, а не методами dbAware компонент

Я в курсе. Если чё.

Anatoly Podgoretsky © (09.08.11 09:07) [34]

> Грид/форма какая разница, редактировать надо в TEdit - то
> есть работать с
> запросами, а не методами dbAware компонент. Тогда всего
> два или один
> коротких запроса SELECT и INSERT/UPDATE.

Ох уж эти сказочники. DBAware-компоненты сами по себе никаких запросов не выдают.

> 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 вполне достаточен в большинстве случаев, имхо.

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

> Inovet © (09.08.11 02:39) [30]

> Надо IBX пользовать

Пользуем. При работе с DBaware проблемы теже. При отображении/редактировании данных в гриде, датасет должен быть открыт и транзакция висеть открытой все то время, что пользователь работает с гридом. Если грид только для чтения, то да можно использовать Read only table stability транзакции. Они стартуют уже закомиченными и на работу конкурирующих транзакций влияния не оказывают.

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

Зачем пункты 1..3?
Запуск приложения - StartReadonlyTransaction
Окончание приложения - Commit
Зачем в CDS переливать? Дабл-кликнул на гриде - открыл модальную форму с данными (причём спецом их из БД перечитал, мало ли кто там чего направил), отредактировал как надо, нажал OK, открыл пишущую транзакцию, залил, закоммитил, перечитал данные в грид.
Вариант с модальной формой может быть заменён на альтернативный, сути дела это не меняет.

asail © (09.08.11 12:52) [37]

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

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

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

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