Подскажите как правильно реализовать следующее:
В основной программе открыта БД через BDE в эксклюзивном режиме. Из DLL, по данным из этой БД, надо построить отчет.

Вопрос: Как правильно обратиться из DLL к этой БД ? ( Открыть отдельную сессию не получится т.к. эксклюзивный досуп к БД )

Просто передача переменной TTable в DLL, вроде как и работает, но не стабильно ( раз через раз слетает программа ).

Очень нужна помощь клуба !!!

скомпилировать программу с ран тайм пакетами и передать переменную Table в DLL

> скомпилировать программу с ран тайм пакетами и передать
> переменную Table в DLL

Так и делаю, но работает не стабильно.

в DLL:

var
 dllBase: TTable;

{$R *.res}

procedure InitReport( _base: TTable ); stdcall;
begin
  dllBase:=_base;
end;

procedure RunReport; stdcall;
begin
   .....
  dllBase.бла бла бла
end;

Вызов из основной программы

var
prgBase: TTable;

InitReport( prgBase ); - тут ошибок не возникает
RunReportRun; - а тут возникают. Статистику набрать в каких случаях не получается т.к. хаотично возникают. Из 5 раз может ни одного не быть, а может и все 5 раз.

--

Выкинуть dll, ибо в озвученном контексте она не нужна и бессмысленна.

TTable это VCL значит своя собственая RTTI в ДЛЛ
ДЛЛ на помойку

Зачем нужна dll?

> Зачем нужна dll?


Ну идея что бы отчеты, используемые в программе, формировать именно через dll. Т.е. формирование отчетов вынести из основной программы. Или есть другие способы решения подобной задачи ? Напомню что БД открывается в эксклюзивном режиме. Подскажите правильное решение плиз

> Т.е. формирование отчетов вынести из основной программы.


Для чего?
З.Ы. Это не стёб, вопрос серьёзный.

> Ega23  (07.11.2011 15:15:08)  [8]

Т.е. формирование отчетов вынести из основной программы.

> Т.е. формирование отчетов вынести из основной программы.


Это я понял. С какой целью это делается?
Эта dll суть "вещь в себе" и разные клиенты имеют возможность делать свой отчёт "с шахматами и поэтессами"?
Это некая "система плагинов"?
Должна ли происходить пересборка exe в случае пересборки dll?
Ну и т.д.

Просто лично мне кажется, что имеет место быть недопонимание, для чего нужна dll.

> [7] P@K   (07.11.11 15:08)
> .е. формирование отчетов вынести из основной программы.

В FastReport это можно делаеть без всяких DLL и перекомпиляции.

Сразу припоминается случай. Когда-то ооочень давно, в 2000-м году начинали разрабатывать систему охраны. В качестве БД был выбран MSSQL. А вот дальше, шеф по каком-то высшим материям и голосам в голове решил, что можно базу разбить на 3 фала: transaction log и 2 файла с данными. При этом мотивация была такая: в одном файле будут лежать всякие разные BLOB-ы, в другом - остальные данные. Оба файла физически находились на одном диске.
Ну а потом, как водится, нет ничего более постоянного, чем временное. Так эта фигня и существовала в виде двух файлов очень долгое время.

Собственно, с dll точно такой же вопрос: действительно ли она нужна в рамка текущей задачи?

> Должна ли происходить пересборка exe в случае пересборки dll?
сколько раз сталкивался с "декларацией" - "можно будет заменять только dll без exe", и ни разу это нормально не работало (может это конечно у нас бардак, но я не с единственной фирмой сталкивался (собственно у нас клиенты - фирмы))...
т.е. кто-то что-то путает, где-то меняются параметры/формы/"сквозная" логика(то что и там и там), и в итоге клиент сначала качает "только нужное" после попарившись и "задолбав" ЦТО качает "все в куче", и только тогда оно начинает работать.

а учитывая то что dll с формой почти = размеру программы... (т.е. всего пара dll с отчетами перекрывает по размеру пару десятков отчетов непосредственно в программе) то...
а вот действительно нафига?

Ну идея что бы отчеты, используемые в программе, формировать именно через dll.

Нормальная идея.
Только зачем длл при этом иметь дело с dbf?
Она должна иметь дело с абстрактными структурированными данными, полученнымивсеравнооткудаеёнекасается

> "можно будет заменять только dll без exe", и ни разу это
> нормально не работало


Вот именно.

> Она должна иметь дело с абстрактными структурированными
> данными, полученнымивсеравнооткудаеёнекасается


плюс стопицот.

> Нормальная идея.
> Только зачем длл при этом иметь дело с dbf?

А кроме того смущает и BDE
:(

> Это я понял. С какой целью это делается?

Именно с этой целью и делается

> сколько раз сталкивался с "декларацией" - "можно будет заменять
> только dll без exe", и ни разу это нормально не работало
> (может это конечно у нас бардак


Это у вас бардак

> Подскажите как правильно реализовать следующее:
> В основной программе открыта БД через BDE в эксклюзивном
> режиме. Из DLL, по данным из этой БД, надо построить отчет.
>
>
> Вопрос: Как правильно обратиться из DLL к этой БД ? ( Открыть
> отдельную сессию не получится т.к. эксклюзивный досуп к
> БД )


Во первых, если программа только разрабатывается, то лучше подумать о гораздо более важной проблеме: уходу от BDE в сторону более современных технологий. Иначе BDE себя еще проявит в будущем, причем далеко не с самой лучшей стороны. Например, уже сегодня приходится сталкиваться с некоторыми сложностями установки и настройки этого добра под Windows7 (тем более x64).
Во вторых, а для чего сделан эксклюзивный доступ? Цель какая?
В третьих, действительно, для чего здесь DLL. Я не буду говорить о "вредности" DLL. Сделать, разумеется, можно по разному, в некоторых случаях без DLL трудно обойтись. Но в данном конкретном случае - зачем?

> сколько раз сталкивался с "декларацией" - "можно будет заменять
> только dll без exe", и ни разу это нормально не работало
> (может это конечно у нас бардак

Согласен, гораздо проще (может на порядок) для разбивки на модули использовать, например, BPL. Но не дай бог кто-то где-то что-то поменял, посыпятся ошибки, концов не отыщешь, придется перекомпилировать все модули. Это не плохо, нормальная ситуация. Плохо будет, если у клиента произойдет мешанина с этими файлами, ведь программа в лучшем случае выкинет AV, а не понятное человеку сообщение "Не могу запуститься, поскольку установлена неправильная версия такого-то файла".

Поясню.
1. BDE взят как пример. Интересует сам механиз работы с открытой БД из DLL. Как правильно передать в DLL возможность доступа к БД. Четких рекомендаций в инете не нашел ни для каких БД.
2. Идея использования DLL в следующем. Хочется сделать некое хранилище алгоритмов построения отчетов в DLL. Перечень этих алгоритмов ест-но может меняться. В основной программе выводится список доступных на текущий момент отчетов ( информация берется из DLL ) и возможность вызова любого из них. Причем механизм вызова для всех отчетов один и тот же. Изменился список или алгоритм отчета - поменял dll и все. Т.е. изменение DLL не влечет за собой перекомпилирование основной программы.

Учитывая, что отчеты - это не основная задача программы, но их много и различных, то всовывать их в код основной программы кажется лишним, дабы не увеличивать объем самой программы.

Вот наверно основные пояснения

P.S. Если что, не судите строго

> Интересует сам механиз работы с открытой БД из DLL.


Если упорно хочется использовать в данной задаче именно DLL, то наиболее коротким путем к намеченной цели будет компиляция всех модулей приложения (EXE, DLL) с run-time-пакетами. Если же этого не сделать, то рискуете потратить огромную уйму времени в поисках различных багов, но так ничего и не найдете.
После компиляции с run-time-пакетами размер модулей приложения будет существенно меньше (разумеется, все необходимые BPL-пакеты придется поставлять вместе с приложением).

DLL является просто областью кода или набором процедур. Ничего фантастического и мешающего коду в DLL работать с базой данных в ней нету, за исключением того, что в DLL и в приложении существуют две копии набора стандартных дельфийских модулей. Пока они между собой не конфликтуют, все происходит хорошо, как только возникает какой-то конфликт, связка DLL и приложение перестает работать. Отсюда следует очевидный вывод - разместить стандартные дельфийские модули в третьей(четвертой и т.п.) DLL - наборе run-time packages, уменьшив тем самым вероятность конфликтов.

Для BDE без run-time packages в стандартной документации рекомендуется создавать свое соединение, размещая TSession и TDatabase в DLL.

> и мешающего коду в DLL работать с базой данных в ней нету
BDE
> Пока они между собой не конфликтуют ... рекомендуется создавать свое соединение
8-12 коннектов и начнут.
а при такой логике минимум 1 коннект на dll. маловато отчетов будет... (у нас 30 минимальный пакет)

> 2. Идея использования DLL в следующем. Хочется сделать некое
> хранилище алгоритмов построения отчетов в DLL. Перечень
> этих алгоритмов ест-но может меняться. В основной программе
> выводится список доступных на текущий момент отчетов ( информация
> берется из DLL ) и возможность вызова любого из них. Причем
> механизм вызова для всех отчетов один и тот же. Изменился
> список или алгоритм отчета - поменял dll и все. Т.е. изменение
> DLL не влечет за собой перекомпилирование основной программы.
>
>
> Учитывая, что отчеты - это не основная задача программы,
>  но их много и различных, то всовывать их в код основной
> программы кажется лишним, дабы не увеличивать объем самой
> программы.


Имхо.
Если в построении этого "хранилища отчетов" участвуют только разработчики  
данного ПО, то лучше обойтись и без dll и без bpl. А объём ПО сейчас мало кого волнует.

> дабы не увеличивать объем самой программы.
программа это не exe, это вся совокупность файлов... так вот обьем у тебя будет к примеру для 10 отчетов - 5 мб. только из dll (по 500 кб.). плюс сама прога, скажем   1.5 мб. ... а вот если все 10 впихнуть в сам exe то размер будет максимум 2 мб. всего, т.е. примерно 11.5 мб. твой "суперэкогном" vs 2 мб. обычный метод.
еще пару задумок на "не увеличение" и DVD под программу заполнишь... :)

> участвуют только разработчики
вот как раз наоборот... если только разработчики то извращайся как хочешь. главное описывай подробно как и с какими версиями работает. но стоит в теплую компанию затесаться хоть одному клиенту... и лафа кончается.

> [21] _P@K   (07.11.11 23:29)
> Хочется сделать некое хранилище алгоритмов построения отчетов в DLL
...

Если только это, то я уже написал

> [11] Inovet ©   (07.11.11 16:58)
> В FastReport это можно делаеть без всяких DLL и перекомпиляции.

> вот как раз наоборот... если только разработчики то извращайся
> как хочешь. главное описывай подробно как и с какими версиями
> работает

А кто это "описание" читает? Кроме самих разработчиков?

>  Как правильно передать в DLL возможность доступа к БД.
> Четких рекомендаций в инете не нашел ни для каких БД.


передавай ConnectionString, а там уже соединяйся так, как хочется, используя при этом те компоненты доступа, которые хочется.

> [30] Ega23 ©   (08.11.11 02:07)
> передавай ConnectionString, а там уже соединяйся так, как
> хочется

У автора ещё эксклюзивный доступ.

> У автора ещё эксклюзивный доступ.


Проблемы индейцев шерифа ...
Вопрос был: Как правильно передать в DLL возможность доступа к БД.

а всего-то и надо - хранить шаблоны отчетов отдельно от программы.
дизайн отчета меняешь - программу не меняешь.

> а всего-то и надо - хранить шаблоны отчетов отдельно от программы.


Да-да, в ini-файлах.

> [34] Ega23 ©   (08.11.11 10:44)
> Да-да, в ini-файлах.

В fr3 файлах.

> Inovet ©   (08.11.11 10:57) [35]
> > [34] Ega23 ©   (08.11.11 10:44)> Да-да, в ini-файлах.В
> fr3 файлах.


Конечно это вариант не плохой, но кол-во fr3 будет столько , сколько отчетов, а их много. Управление большим кол-вом файлов - это уже отдельное неудобство.

В принципе понятно, что выбранный вариант решения не самый оптимальный. Спасибо всем за разъяснения. Буду думать на чем остановиться

> [36] P@K   (08.11.11 11:48)
> но кол-во fr3 будет столько , сколько отчетов, а их много.
> Управление большим кол-вом файлов - это уже отдельное неудобство.

Храни в базе хоть список fr3, хоть сами формы (это возможно штатными средствами ФР), или ещё как-нибудь. Главное, что не надо перекомпилировать ни строчки.

Управление большим кол-вом файлов - это уже отдельное неудобство.

Чем отличается управление двумя файлами от управления большим количеством файлов?

Существует ли фар для папок с двумя файлами и фар для папок с большим количеством файлов?
Если фара нет, то может быть есть проводник ?

Опять все свелось к "ржавой" консерватории :)

>Ega23 ©   (08.11.11 10:44) [34]
>> а всего-то и надо - хранить шаблоны отчетов отдельно от программы.
>Да-да, в ini-файлах.

Зачем же ? В самой базе разумеется.

> Чем отличается управление двумя файлами от управления большим
> количеством файлов?


Как минимум тем, что если много отчетов и каждый в своем отдельном fr, то надо иметь их список и постоянно контролировать наличие онных.

> то надо иметь их список и постоянно контролировать наличие онных.
вовсе нет... нужно только запрограммировать механизм (типа смотрим папку/файлы отчетов/или настройки в ini/xml/... ), и отдать его(программу) в службу поддержки.
кому надо делает себе новый отчет и кладет в папку... тебя не должно волновать даже как его назовут... не нужно существующего - удаляет, хоть все, механизм работает с тем, что есть.

p.s. у меня не fr..., но по принципу обработки... какая разница?

отдельными файлами проще в обслуживании.

Разговор зашел в другое русло от вопроса. Хотя советы скорее правильные, но на сам вопрос мне так никто не ответил - "Как правильно обратиться из DLL к БД ?". Обсуждение свелось к объяснению почему мне это не надо, вместо как это сделать :(

Изобретать корявые велосипеды с треугольными колёсами не интересно.

вам по ходу ветки предложили несколько относительно правильных способов обращения из длл к бд.

> Подскажите правильное решение плиз

Уже подсказали - выкинуть ДЛЛ, ты все равно с ними не умеешь работать.

> _P@K   (11.11.11 01:25) [44]
>
> Разговор зашел в другое русло от вопроса. Хотя советы скорее
> правильные, но на сам вопрос мне так никто не ответил -
> "Как правильно обратиться из DLL к БД ?". Обсуждение свелось
> к объяснению почему мне это не надо, вместо как это сделать
> :(

Читай http://www.gunsmoker.ru/2008/10/x-y-z.html