Рискну спросить...

Имеется в наличии довольно большая база данных в билдере, при этом очень активно использованы элементы закладки DataContlols.
В этом есть свои плюсы, но как выяснилось минусов тоже достаточно.
Просто база сначала планировалась однопользовательской, а терь плавно переходит в много....

Возник вопрос, а не лучше ли было использовать обычные элементы, заполняя их при открытии, и записывая при нажатии на ок?

Здравствуйте, Ptaha, Вы писали:

P>Возник вопрос, а не лучше ли было использовать обычные элементы, заполняя их при открытии, и записывая при нажатии на ок?

Хм. Ну если решительно нечем занять время — можно, конечно, и так. Но кроме этого — ничем не лучше, исключительно наоборот.

Здравствуйте, Softwarer, Вы писали:

S>Хм. Ну если решительно нечем занять время — можно, конечно, и так. Но кроме этого — ничем не лучше, исключительно наоборот.

Может я что-нить делаю не так?
у меня MDI-приложение..Необходимо дать возможность пользователю открывать несколько окон одновременно, но при этом нужно время от времени обновлять инфу из базы (если были заполнены другие, вспомогательные таблицы, из которых данные попадают в LookUp-элементы). Поэтому, при активации формы запрос переактивируется, и следовательно если были внесены изменения, но не сохранены, то они теряются. Сохранять запись каждый раз при потере фокуса — совсем плохо.

модель ситуации: пользователь заполняет документ (1-я форма), в это время вспоминает, что ему нужно заполнить справочник (2-я форма), причем данные из этого справочника должны попасть в 1-ю форму. Он открывает соответственно справочник...

Здравствуйте, Ptaha, Вы писали:

P>у меня MDI-приложение..Необходимо дать возможность пользователю открывать несколько окон одновременно, но при этом нужно время от времени обновлять инфу из базы (если были заполнены другие, вспомогательные таблицы, из которых данные попадают в LookUp-элементы).

А что за лукап-элементы? Вообще говоря, я бы не советовал пользоваться lookup-полями; для небольших приложений они применимы, но лучше не приобретать вредную привычку

Лично я предпочитаю запрашивать данные справочника в тот момент, когда пользователь собственно и начинает выбор из справочника. Кэшировать справочник на клиенте — в принципе можно; принципиальных проблем для этого тоже не вижу; на худой конец, если это будет самым простым, можно воспользоваться ClientDataSet-ом.

P> Поэтому, при активации формы запрос переактивируется,

Какой? Если датасет "основных данных" — мягко говоря, непонятно зачем. Если какой-то лукаповский — хм, во-первых см. выше, во-вторых, если вдруг изменения в лукаповском запросе передергивают основной (что очень странно), значит, надо вставить между ними какой-нибудь буфер, опять же любой ClientDataSet, MemTable итп.

P> и следовательно если были внесены изменения, но не сохранены, то они теряются. Сохранять запись каждый раз при потере фокуса — совсем плохо.

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

P>модель ситуации: пользователь заполняет документ (1-я форма), в это время вспоминает, что ему нужно заполнить справочник (2-я форма), причем данные из этого справочника должны попасть в 1-ю форму. Он открывает соответственно справочник...

В том подходе, который предпочитаю я, он открывает справочник, вставляет редактирует данные, и когда жмет наконец Enter — данные вставляются в базу, а кроме того возвращаются в первую форму. Та, соответственно, заполняет поля своего датасета (включая псевдолукаповские). Впрочем, это не единственный подход.

Здравствуйте, Softwarer, Вы писали:

S>А что за лукап-элементы? Вообще говоря, я бы не советовал пользоваться lookup-полями; для небольших приложений они применимы, но лучше не приобретать вредную привычку

S>Лично я предпочитаю запрашивать данные справочника в тот момент, когда пользователь собственно и начинает выбор из справочника. Кэшировать справочник на клиенте — в принципе можно; принципиальных проблем для этого тоже не вижу; на худой конец, если это будет самым простым, можно воспользоваться ClientDataSet-ом.

DBLookupComboBox в основном.. Приходится конектится сразу, так как некоторые данные проставляются по умолчанию

P>> Поэтому, при активации формы запрос переактивируется,
S>Какой? Если датасет "основных данных" — мягко говоря, непонятно зачем. Если какой-то лукаповский — хм, во-первых см. выше, во-вторых, если вдруг изменения в лукаповском запросе передергивают основной (что очень странно), значит, надо вставить между ними какой-нибудь буфер, опять же любой ClientDataSet, MemTable итп.

все правильно, просто может быть длинная цепочка открытия из-под одних форм другими, и по этому хотелось написать нечто универсальное. отсюда — переконект всего

S>Хм. И в конце концов, если уж идти по пути наименьшего сопротивления, можно запускать обновление только при отсутствии редактируемых записей.
неудобно пользователю

P>>модель ситуации: пользователь заполняет документ (1-я форма), в это время вспоминает, что ему нужно заполнить справочник (2-я форма), причем данные из этого справочника должны попасть в 1-ю форму. Он открывает соответственно справочник...
S>В том подходе, который предпочитаю я, он открывает справочник, вставляет редактирует данные, и когда жмет наконец Enter — данные вставляются в базу, а кроме того возвращаются в первую форму. Та, соответственно, заполняет поля своего датасета (включая псевдолукаповские). Впрочем, это не единственный подход.
опять таки может быть длинная цепочка

Здравствуйте, Ptaha,

Не делай отдельных DataSet'ов для lookup источников данных. Используй одни и те же.

Здравствуйте, Ptaha, Вы писали:

P>все правильно, просто может быть длинная цепочка открытия из-под одних форм другими, и по этому хотелось написать нечто универсальное. отсюда — переконект всего

Хм. Не вижу логики в этом "отсюда" Кроме того, мне кажется это ответ не совсем на то, что я говорил и спрашивал.

"Всего" — это чего именно всего? Всех датасетов, которые вообще есть в приложении?

P>неудобно пользователю

Хм. Просто я вряд ли мог предусмотреть, что Вы используете этот механизм для общения объектов внутри приложения. Я полагал, обновление запускается для учета изменений, сделанных другими пользователями.

P>опять таки может быть длинная цепочка

И что из этого? Длинная цепочка правильно работающих элементов, каждый из которых знает свой интерфейс. Идеальный подход с точки зрения общей теории.

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

Здравствуйте, Softwarer, Вы писали:

P>>опять таки может быть длинная цепочка

S>И что из этого? Длинная цепочка правильно работающих элементов, каждый из которых знает свой интерфейс. Идеальный подход с точки зрения общей теории.

S>Хм. Задекларирую одно утверждение: при правильно выстроенных взаимодействиях (что есть ключевая задача проектирования) количество взаимодействующих элементов не играет роли; если правильно взаимодействуют каждые два элемента в цепочке, правильно работать будет цепочка любой длины.

Пришло на ум одно извратное решение:
— Форма самого нижнего уровня при завершении редактирование шлет через PostMessage() сообщение, на которое реагирует самая верхняя форма (Application.MainForm например)
— MainForm дергает все открытые формы более нижнего уровня на предмет выполнения RefreshData();

Здравствуйте, DarkMaster, Вы писали:

DM>Пришло на ум одно извратное решение:

Можно менее извращенно. http://softwarer.ru/Describe/describe_stsnotifier.html

Здравствуйте, Softwarer, Вы писали:

P>>все правильно, просто может быть длинная цепочка открытия из-под одних форм другими, и по этому хотелось написать нечто универсальное. отсюда — переконект всего
S>Хм. Не вижу логики в этом "отсюда" Кроме того, мне кажется это ответ не совсем на то, что я говорил и спрашивал.

S>"Всего" — это чего именно всего? Всех датасетов, которые вообще есть в приложении?
не, ток тех, которые есть на форме

P>>неудобно пользователю
S>Хм. Просто я вряд ли мог предусмотреть, что Вы используете этот механизм для общения объектов внутри приложения. Я полагал, обновление запускается для учета изменений, сделанных другими пользователями.


P>>опять таки может быть длинная цепочка
S>И что из этого? Длинная цепочка правильно работающих элементов, каждый из которых знает свой интерфейс. Идеальный подход с точки зрения общей теории.

S>Хм. Задекларирую одно утверждение: при правильно выстроенных взаимодействиях (что есть ключевая задача проектирования) количество взаимодействующих элементов не играет роли; если правильно взаимодействуют каждые два элемента в цепочке, правильно работать будет цепочка любой длины.

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

Здравствуйте, Ptaha, Вы писали:

S>>"Всего" — это чего именно всего? Всех датасетов, которые вообще есть в приложении?
P>не, ток тех, которые есть на форме

То есть: сначала Вы размахиваетесь кувалдой, а потом боретесь с тем, что под удар попало что-то лишнее. Может быть действовать более избирательно?

P>ясно.. прийдется повозится.. я просто думала что проще будет при входе — заполнить форму из запроса в обычные элементы (в смысле не связанные с БД), а по нажатию ок — записать..
P>но если это концептуально не правильно... будем возится

Это не то что концептуально неправильно; на самом деле DBControl-ы внутри себя именно это и делают Это просто большое количество абсолютно тупой и чреватой ошибками работы. Кроме того, как и любой неосмысленный код, такое решение снижает качество программного решения (программа становится менее удобной для понимания, более дорогой в сопровождении и т. д.) Ну и наконец, это отсекает большое количество dbaware-решений, для которых нет "нормальных" аналогов.

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

Здравствуйте, Ptaha, Вы писали:

P>Здравствуйте, Softwarer, Вы писали:

S>>Хм. Ну если решительно нечем занять время — можно, конечно, и так. Но кроме этого — ничем не лучше, исключительно наоборот.

P>Может я что-нить делаю не так?
P>у меня MDI-приложение..Необходимо дать возможность пользователю открывать несколько окон одновременно, но при этом нужно время от времени обновлять инфу из базы (если были заполнены другие, вспомогательные таблицы, из которых данные попадают в LookUp-элементы). Поэтому, при активации формы запрос переактивируется, и следовательно если были внесены изменения, но не сохранены, то они теряются. Сохранять запись каждый раз при потере фокуса — совсем плохо.

P>модель ситуации: пользователь заполняет документ (1-я форма), в это время вспоминает, что ему нужно заполнить справочник (2-я форма), причем данные из этого справочника должны попасть в 1-ю форму. Он открывает соответственно справочник...

Лучше использовать простые контролы типа TComboBox и прочее и заполнять на открытии. И придумать систему сообщений (как простых, так и сетевых), а при изменении инфы в другом окне — посылать сообщение что, мол, "изменена запись №2 в справочнике №3", а на формах, где элементы из справочника №3 используются, ловить события об изменении или добавлении этих записей и изменять только ту часть что изменилась.
Сумбурно объяснил, но, надеюсь, понятно (:

S>Это не то что концептуально неправильно; на самом деле DBControl-ы внутри себя именно это и делают Это просто большое количество абсолютно тупой и чреватой ошибками работы. Кроме того, как и любой неосмысленный код, такое решение снижает качество программного решения (программа становится менее удобной для понимания, более дорогой в сопровождении и т. д.) Ну и наконец, это отсекает большое количество dbaware-решений, для которых нет "нормальных" аналогов.

S>Также я бы указал на очень опасную тенденцию: Вы принимаете одно неудачное решение (дергать все подряд), натыкаетесь на связанную с ним проблему, и вместо того, чтобы скорректировать подход, заново оценить ситуацию в целом — принимаете другое, еще более неудачное решение, следующее из постулата о непогрешимости первого. В результате такой практики программа очень быстро превратится в огромную и сложную конструкцию из костылей, занятых в основном поддержкой друг друга. При любой попытке доработки такая программа будет рассыпаться как карточный домик.

убили.. наповал.. я в общем по этому и решила заподозрила, что делаю что-то не то
спасибо за разяснение

Здравствуйте, .silent, Вы писали:

S>Сумбурно объяснил, но, надеюсь, понятно (:
спасибо, понятно.. система сообщений, эт конечно весчь нужная, особенно если продуманная

Тогда искну задать еще один вопрос, в связи со всем предыдущим..

у меня в проге несколько дата-модулей, где располагаются компоненты TIBDataBase, TibTransaction, TIBDataSet, TDataSource.
TIBDataSet, TDataSource, расположенные на формах подключаются соответственно к базам и транзакциям в дата-модулях
Не следует ли для каждой формы сделать свою транзакцию

P>Тогда искну задать еще один вопрос, в связи со всем предыдущим..

P>у меня в проге несколько дата-модулей, где располагаются компоненты TIBDataBase, TibTransaction, TIBDataSet, TDataSource, TIBDataSet, TDataSource, расположенные на формах подключаются соответственно к базам и транзакциям в дата-модулях Не следует ли для каждой формы сделать свою транзакцию

Ну, это зависит от БД.
Например, для MS SQL Server и вообще всех "блокировщиков" — однозначно не следует. Потому что транзакции из разных форм могут заблокировать друг друга. Транзакций должно быть мало — вообще, как можно меньше.

А для Oracle (или другого "версионника")? Ну, вероятно эффект будет не так заметен... Не знаю.

Здравствуйте, Ptaha, Вы писали:

P>Не следует ли для каждой формы сделать свою транзакцию

Это больше зависит от постановки задачи. В принципе это нормальный подход, и задачи работы с документами часто делают именно так.

Здравствуйте, Arsu, Вы писали:

P>>Тогда искну задать еще один вопрос, в связи со всем предыдущим..

P>>у меня в проге несколько дата-модулей, где располагаются компоненты TIBDataBase, TibTransaction, TIBDataSet, TDataSource, TIBDataSet, TDataSource,
A>А для Oracle (или другого "версионника")? Ну, вероятно эффект будет не так заметен... Не знаю.

компоненты TIBDataBase, TibTransaction, для Oracle???
не, у нас Interbase.
а про заблокировать.эт конечно прийдется пересматривать отдельно
но если транзакция будет находится только в дада-модуле, то может быть такая ситуация:
открыты 2 записи одной таблицы в 2-х разных формах.. после этого одна запись корректируется и сохраняется, а вторая — не получает об этом никакой информации, без переактивации запроса.. а насчет переактивации основного запроса к форме уже было выше..

Здравствуйте, Softwarer, Вы писали:

S>Здравствуйте, Ptaha, Вы писали:

P>>Не следует ли для каждой формы сделать свою транзакцию

S>Это больше зависит от постановки задачи. В принципе это нормальный подход, и задачи работы с документами часто делают именно так.

спасибо, очень помогли

P>>>Тогда искну задать еще один вопрос, в связи со всем предыдущим..

P>>>у меня в проге несколько дата-модулей, где располагаются компоненты TIBDataBase, TibTransaction, TIBDataSet, TDataSource, TIBDataSet, TDataSource,
A>>А для Oracle (или другого "версионника")? Ну, вероятно эффект будет не так заметен... Не знаю.

P>компоненты TIBDataBase, TibTransaction, для Oracle???
P>не, у нас Interbase.

Ой, и правда

P>а про заблокировать.эт конечно прийдется пересматривать отдельно
P>но если транзакция будет находится только в дада-модуле, то может быть такая ситуация:
P>открыты 2 записи одной таблицы в 2-х разных формах.. после этого одна запись корректируется и сохраняется, а вторая — не получает об этом никакой информации, без переактивации запроса.. а насчет переактивации основного запроса к форме уже было выше...

Я слышал краем уха, что для внесения изменений в БД принято использовать 2 метода — "оптимистическая блокировка" и "пессимистическая блокировка". Пессимистическая — это когда эксклюзивно блокируют ресурсы в самом начале редактирования, и, следовательно, параллельно редактировать одно и то же просто невозможно. Оптимистическая — это когда ресурсы блокируются в момент сохранения изменений — это, конечно, повышает параллельность и масштабируемость и всё такое, но есть проблема, которую ты указала (я правильно пол уловил? если нет, то заранее прощу прощения...) — надо поставлять обновления после сохранения и ловить попытки затереть сохранённое новое — старыми данными.

Я так понял, что ты используешь именно оптимистическую блокировку. Однако тут тоже есть два подхода — начинать транзакцию в момент начала редактирования или же начинать её при сохранении.

В первом случае — если второй человек попытается сохранить изменения поверх уже сохранённых, то БД ему скажет — гуд-бай, парниша, у тебя старые данные. И все его изменения будут утеряны (в БД не сохранятся).
Во втором случае — если второй человек попытается сохранить изменения поверх уже сохранённых, то всё будет ОК. Но будут потеряны данные первого юзера.

Первый вывод. Если ты используешь TDBEdit'ы и т.п. в том же духе — то есть компоненты прямого доступа в БД, то ты при наложении изменений — теряешь данные (или первого юзера, или второго).
Второй вывод. Если используешь оптимистичекую блокировку, то конфликты надо регулировать. Ручками чаще всего.

Куда определить транзакции — это, конечно, вопрос. Однако хочу заметить, что ты будешь создавать по транзакции на окно, то это не решит проблему потери данных. А если это не решает проблем, то зачем это делать?

Проблема, мне кажется, именно в этом — как обрабатывать конфликты при сохранении изменений.

Мне лично кажется логичным, если эти конфликты будет решать нечто в единственном экземпляре — соответственно, и транзакция у этого "нечто" может быть всего одна — так и так он всех в очередь построит.