Синхронизация таблиц БД

← →
Loginov Dmitry © (2006-02-16 16:47) [0]

Добрый день, мастера! Проблема следующая: имеется база данных Interbase (одна табличка), dll-библиотека и основная прога. Работа с табличкой выполняется как в dll, так и в основной программе. Т.е. и там и там имеется TDataModule с компонентами TIBDataBase, TIBSataSet, TIBDataSource, TIBTransaction.
Нужно, чтобы при перемещении по табличке в основной проге, выполнялось перемещение по такой же табличке в dll (И наоборот). Причем, при добавлении, удалении и редактировании записи (как в основной программе, так и в dll) изменения происходили синхронно.

Пока я добился только синхронного перемещения по записям. Для этого использовал метод OnAfterScroll(), однако при любых изменениях данных этот метод уже не годится (во многом благодаря тнанзакции).

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

← →
Desdechado © (2006-02-16 17:19) [1]

а зачем тебе эта "синхронизация"? любитель трудностей?

> можно ли установить ссылку в основной программе на набор данных, находящийся в dll
можно, передай через параметры функции инициализации DLL место, куда потом присвоишь этот указатель
но, имхо, лучше наоборот - датасет в основной программе (и один на EXE+DLL), а отображение можно в DLL
но все равно неявно назначение плясок...

← →
Loginov Dmitry © (2006-02-16 18:01) [2]

> Desdechado © (16.02.06 17:19) [1]
>
> а зачем тебе эта "синхронизация"?

В dll я храню различные формы и процедуры, которые могут использоваться различными приложениями. Имеется таблица пациентов и дочерняя таблица посещений. Допустим, в основной проге пользователь выбирает пациента и жмет на кнопку "Снять ЭКГ". В результате вызывается форма для снятия ЭКГ, хранимая в dll. После снятия ЭКГ происходит запись сигналов ЭКГ в таблицу посещений (при этом добавляется новая запись). Далее необходимо обработать сигналы ЭКГ в основной проге - но этих сигналов в ней не видно - мешает транзакция.

> любитель трудностей?

Скорее наоборот, хочу обойти трудности, поэтому и прошу совета мастеров.

> можно, передай через параметры функции инициализации DLL
> место, куда потом присвоишь этот указатель

Нужно не любое место, а правильное место, а вот что является правильным местом - я не знаю.

> датасет в основной программе (и один на EXE+DLL), а отображение
> можно в DLL

Вот как это сделать - один датасет на EXE+DLL?

>DesWind © (16.02.06 17:22) [1]

>Передай в основную программу DataSource из dll.

Invalid Pointer Operation

← →
Desdechado © (2006-02-17 12:34) [3]

как вариант, можно сделать:
1. основная прога вызывает некую функцию из DLL, в которую передает TIBDataBase
2. DLL его использует, создавая свои объекты, манипулируя с ними. Все формы в DLL - модальные. Завершение главной формы DLL выдает статус основной программе. Данные сохраняются или откатываются.
3. Основная программа на основе анализа статуса при необходимости обновляет датасеты у себя, вычитывая изменения, сделанные в DLL.

← →
Desdechado © (2006-02-17 12:37) [4]

да, не забудь:
1. в DLL передать Application.Handle для
function MyFunc( App: HWND; db: TSQLConnection ): CARDINAL; stdcall; var hOldHandle: HWND; begin hOldHandle := Application.Handle; Application.Handle := App; result := ProcessData( db ); Application.Handle := hOldHandle; end;
2. помни, что DLL и EXE должны быть скомпилированы одной версией Delphi для корректной работы объектных ссылок

← →
Loginov Dmitry © (2006-02-17 15:50) [5]

Да уж, похоже, что без трудностей здесь никак не обойтись :)

А можно ли проделать такой фокус: в DLL находится форма с панелькой. На панельке находится куча всяких элементов, в т.ч. и DBGrid. Можно ли данную панельку разместить на форме в основной проге. Если да, то как это сделать? (Мои попытки сводятся пока к Invalid Pointer Operation)

> 2. помни, что DLL и EXE должны быть скомпилированы одной
> версией Delphi для корректной работы объектных ссылок

А вот это дельный совет. Учтем :)

← →
Desdechado © (2006-02-17 16:21) [6]

> Можно ли данную панельку разместить на форме в основной проге.
Наверно, можно. Передав в DLL указатель на эту форму. А зачем такие изыски?

← →
Loginov Dmitry © (2006-02-17 18:57) [7]

> Наверно, можно. Передав в DLL указатель на эту форму.

Я тоже считал, что можно, но сколько ни пытался - ничего не выходит :(

> А зачем такие изыски?

Какие уж тут изыски. Просто проект на самом деле очень серьезный и хочется обеспечить максимальню функциональность с минимальными усилиями.

← →
Desdechado © (2006-02-17 19:02) [8]

> ничего не выходит
Юнит с этой формой должен быть прикомпилирован к DLL.
Я уже говорил о соблюдении одинаковости описания классов. Свои формы - тоже классы.

← →
Desdechado © (2006-02-17 19:04) [9]

и еще раз - попробуй Desdechado © (17.02.06 12:34) [3]
в этом случае разделяетсятолько подключение к БД, остальное независимо и легко управляемо
твой вариант вместо "максимальню функциональность с минимальными усилиями" будет "с максимальными проблемами"

← →
atruhin © (2006-02-17 19:31) [10]

Не нужно ничего сихронизировать. В dll передаешь только ID пациента. После того как она отработала, обновляешь данные в приложении. Я писал диспетрчер событий, каждое окно может подписаться на любые события производимые с данными другими окнами (например событие обновления списка пациентов или кардиограмм), окно производящее изменения вызывает события, т.е. на этапе проектирования окна друг о друге знать не знают.
Как в IBDatabase не помню, но в fibDatabase можно передать Handle подключенного fibDatabase и тот будет использовать данное подключение.
Все взаимодействие лучше описать как интерфейс .

← →
Loginov Dmitry © (2006-02-17 20:17) [11]

> atruhin © (17.02.06 19:31) [10]

Так и думал, что без гемора здесь не обойдешься :)
Похоже, придется обмениваться ключами, а что делать?

Как я понял, между основной прогой и DLL-кой вообще невозможно осуществить обмен элементов форм. Только и знает, что "Cannot assign a TFont to a TFont".

← →
Desdechado © (2006-02-17 21:01) [12]

atruhin © (17.02.06 19:31) [10]
в общем то, что я и описал :)

← →
API (2006-02-17 21:14) [13]

Как я понял, между основной прогой и DLL-кой вообще невозможно осуществить обмен элементов форм

Отчего же, возможно. Навскидку, три варианта:

- WinAPI;
- COM;
- "велосипед", но его изобретать придется.

P.S. ICQ в анкете - "мертвая"?

← →
Джо © (2006-02-17 21:17) [14]

> [11] Loginov Dmitry © (17.02.06 20:17)
> Как я понял, между основной прогой и DLL-кой вообще невозможно
> осуществить обмен элементов форм.
> assign a TFont to a TFont".

Разработай интерфейс взаимодействия DLL с основной программой.
Например, DLL, желающая создавать кнопки на тулбаре, должна экспортировать следующие функции:function GetButtosCount: Integer; function GetButtonCaption (Index: Integer): PChar; function GetButtonBitmap (Index: Integer): HBitmap procedure ClickButton (Index: Integer);
Основная программа, загружая DLL, вызываеи их, создавая кнопки на тулбаре с нужными надписями, картинками и т.п. и выполняя ассоциированное действие при щелчке на них.

← →
Loginov Dmitry © (2006-02-17 21:30) [15]

> P.S. ICQ в анкете - "мертвая"?

Нет, живая. Просто аська немного выключена :)

> Джо © (17.02.06 21:17) [14]

Ну это понятно, но в данном случае придется подключать все необходимые модули.

← →
Джо © (2006-02-17 21:44) [16]

> [15] Loginov Dmitry © (17.02.06 21:30)
> Ну это понятно, но в данном случае придется подключать все
> необходимые модули.

Не понял.

← →
Loginov Dmitry © (2006-02-17 22:00) [17]

> Не понял.

Насколько я понял, в основной проге должен создаваться объект, допустим TButton, свойства которого в дальнейшем и будут настраиваться. Класс кнопки объявлен в каком-то модуле, поэтому его придется подключить. Подключение некоторых модулей увеличивает размер exe"шки довольно значительно - вот это и имелось ввиду в предыдущем посту.

← →
API (2006-02-17 22:11) [18]

см. TWinControl.ParentWindow

> [17] Loginov Dmitry © (17.02.06 22:00)

Не вижу ничего страшного в увеличении размера "экешки", тем более, если речь идеть о 50-100-200 Кб. Впрочем, не настаиваю.

Ну все, вроде решил проблему. Синхронизацию сделал по ключу. Если в DLL изменили или добавили запись, то делается Commit и открываются заново таблички в DLL, после чего тоже самое делается в основной проге.

Спасибо всем, кто принял участие!

← →
API (2006-02-18 00:51) [21]

открываются заново таблички в DLL, после чего тоже самое делается в основной проге

А я все размышляю, к чему все эти процессорные гигагерцы и Gigabit Ethernet?

Я сильно извиняюсь, но по-моему напрашивается использование run-time packages с выносом необходимого datamodule c dataset в отдельный пакет. Он точно будет один для всех и никаких cannot assing tfont to tfont не будет...

> выносом необходимого datamodule c dataset в отдельный пакет

??? а как это сделать?

← →
REA (2006-02-18 14:06) [24]

Если не планируется других языков, то вариант [22] будет наменее болезненным.

> Если не планируется других языков, то вариант [22] будет
> наменее болезненным.

В дальнейшем другие языки планируются. Приложение серьезное, и за него деньги платить будут нашей "фирме", и не малые (но пока это в отдаленной перспективе :).

А как осуществить [22] я не знаю, еще не изучил данную технологию. Где про это можно почитать?

runtime package - это DLL специального вида, совместимая только с Дельфи той же версии, что и EXE сделан
в ней не хранятся копии описаний классов из основной ЕХЕ, что удобно с т.з. объема и лекгости программирования, но несовместимо с другими языкамии версиями Дельфи

Синхронизация таблиц БД Найти похожие ветки