Удалите TDataModule, но оставьте TADOConnection без изменений
У меня есть библиотека с некоторыми TDataModules, которые разделяют TADOConnection. Я создаю и удаляю модули данных в некоторых приложениях.
Когда я удаляю модуль данных, я получаю ошибку EAccessViolation. Я думаю, что это связано с тем, что модуль данных хочет удалить TADOConnection, который является общим.
Я попытался установить свойство tdatamodule-> tbquery-> Connection в NULL, когда вызывается деструктор, но безуспешно.
Почему я думаю, что ошибка находится в TADOConnection? Потому что, когда я создаю свое приложение без lib, я могу создавать и удалять модули данных без проблем. И когда я создаю библиотеку с модулями данных, которые имеют собственное соединение, у меня тоже нет проблем.
Любая помощь? Заранее спасибо!
Ошибка:
http://oi60.tinypic.com/noyc6x.jpg
Стек вызовов:
http://oi61.tinypic.com/sgljx5.jpg
Решение
TDataModule освобождает только то, что ему принадлежит. Если вы делитесь одним TADOConnection в нескольких TDataModule экземпляры тогда они не могут все владеть этим. Однако, возможно, вы освобождаете Владельца и не информируете другие случаи, что TADOConnection освобождается. У VCL есть механизм для этой цели — TComponent::FreeNotification() метод. Ваш TDataModule объекты могут перекрывать виртуальные Notification() метод, а затем вызвать FreeNotification() на TADOConnection, Таким образом, если TADOConnection когда-либо освобожден, любой TDataModule использующий его, может действовать соответствующим образом, например, устанавливая свой локальный указатель на NULL, чтобы они знали TADOConnection ушел
Другие решения
Решение добавляет borlndmm.dll в папку проекта приложения, используя библиотеки или библиотеки DLL.
Из проектов dll / lib в Borland C ++ Builder:
//---------------------------------------------------------------------------
// Important note about DLL memory management when your DLL uses the
// static version of the RunTime Library:
//
// If your DLL exports any functions that pass String objects (or structs/
// classes containing nested Strings) as parameter or function results,
// you will need to add the library MEMMGR.LIB to both the DLL project and
// any other projects that use the DLL. You will also need to use MEMMGR.LIB
// if any other projects which use the DLL will be performing new or delete
// operations on any non-TObject-derived classes which are exported from the
// DLL. Adding MEMMGR.LIB to your project will change the DLL and its calling
// EXE's to use the BORLNDMM.DLL as their memory manager. In these cases,
// the file BORLNDMM.DLL should be deployed along with your DLL.
//
// To avoid using BORLNDMM.DLL, pass string information using "char *" or
// ShortString parameters.
//
// If your DLL uses the dynamic version of the RTL, you do not need to
// explicitly add MEMMGR.LIB as this will be done implicitly for you
//---------------------------------------------------------------------------