> Подскажите как правильно реализовать следующее:
> В основной программе открыта БД через 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, хоть сами формы (это возможно штатными средствами ФР), или ещё как-нибудь. Главное, что не надо перекомпилировать ни строчки.

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

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

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

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