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

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

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

Ой, и правда

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

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

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

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

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

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

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

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