Мне вообще ничего практически не надо делать (изменять приложение), чтобы работать с большинством SQL-серверов :))
Более того, обеспечена одновременно работа с многими SQL-серверами одним приложением. :))

> Мне вообще ничего практически не надо делать (изменять приложение),
>  чтобы работать с большинством SQL-серверов :))
> Более того, обеспечена одновременно работа с многими SQL-
> серверами одним приложением. :))


У слона всё равно длиннее.
И толще.

Почитал. Хочется сначала попробовать метод [5]. Однако не получается увидеть свойство MySuperMegaDataModule в дизайнере объектов. Не подскажите решение / ссылочку. Спасибо

Если рассматривать приложение в рамках парадигмы Model-View-Controller, то базовый datamodule вполне может быть абстрактной моделью, а его наследники - конкретными моделями.
Не вижу ничего криминального в создании наследников datamodule, единственное что предложу автору - это не ссылаться нигде по имени на переменную конкретного экземпляра datamodule типа MyDm.MyDataSet

[23] Допустим в коде я могу убрать ссылки (и то думаю будет непривычно), но как быть с ссылками в дизайн-тайме? Думается, что все-таки писать привязки в рантайме слишком громоздко

> Думается, что все-таки писать привязки в рантайме слишком
> громоздко


Советую писать их именно в ран тайм.
Дело в том, что в силу некоторых косяков среды (а именно, периодического обниливания ссылок на внешние модули\формы в дизайнере), удобство работы "мышкой" полностью портится необходимостью ведения борьбы с этими "фичами"

> но как быть с ссылками в дизайн-тайме?


какие ссылки в design-time имеются в виду ?

>Ega23 ©   (14.01.09 14:37) [18]
>Всё потомок TDataSet.

Кхе-кхе два раза, но, извиняюсь, кто у пресловутого датасета в отцах ходит, ась ?

>Jeer ©   (14.01.09 15:04) [20]
>Более того, обеспечена одновременно работа с многими SQL-серверами одним приложением. :))

Осталось только выяснить крохотный вопросец - а что, собсна, умеет делать это самое приложение ? :)

>Медвежонок Пятачок ©   (14.01.09 14:43) [19]
>Базовый модуль данных ничего не знает о компонетах (bde,ado,fibs,odac etc)
>И про сервер ничего не знает. Это может быть любой сервер или вообще файлы dbase/paradox
>Но он все знает о том, как должны делаться инсерты/апдейты/делеты и прочее. Содержит всю >бизнес логику и все алгоритмы.

А какой сиквель использует этот замечательный датамодуль и как на этот сиквель реагируют "любые" сервера ?
И я все же так и не добился ответа на главное - а разве все это нельзя было сделать без датамодуля, а если можно, то в чем все-таки преимущество именно датамодуля ?

>Когда мне нужно зарелизить версию на новом сервере с новыми компонентами доступа, я просто >создаю потомка, добавляю в него конннекшен, пару дататсетов, и переопределяю порядка >десятка методов.

Чем эта парадигма предпочтительнее следующей:
"Когда я реализую новый сервер, то в первую очередь использую функционал библиотеки, а если его недостаточно, то пишу свой, иногда перенося его в те же библиотеки, расширяя их функции и уменьшая таким образом трудоемкость проектирования в перспектие ?"

> MsGuns ©   (14.01.09 17:20) [27]
> >Jeer ©   (14.01.09 15:04) [20]
> >Более того, обеспечена одновременно работа с многими SQL-
> серверами одним приложением. :))
>
> Осталось только выяснить крохотный вопросец - а что, собсна,
>  умеет делать это самое приложение ? :)
>


OLAP

ну ты эта.. реально крут :)

> какие ссылки в design-time имеются в виду ?

Допустим привязка TADODataSet.Connection = TADOConnection в инспекторе свойств


> Дело в том, что в силу некоторых косяков среды (а именно,
>  периодического обниливания ссылок на внешние модули\формы
> в дизайнере), удобство работы "мышкой" полностью портится
> необходимостью ведения борьбы с этими "фичами"

Слышал про проблему. Но если в проекте держать открытым датамодуль, то проблема исчезнет. По крайней мере видел этот способ решения

> Допустим привязка TADODataSet.Connection = TADOConnection
> в инспекторе свойств


В моем (например) случае connection хранится в своем datamodule не входящем в иерархию (connection-ов обычно меньше, чем DataSet-ов), соответственно, ссылка в design-time тоже наследуется.
Если очень боязно за то, что пропадет, можно на событии Loaded предка в иерархии присвоить это свойство в run-time, тогда оно автоматически распространится на наследников.

>Рыбба   (14.01.09 17:44) [30]
>> Дело в том, что в силу некоторых косяков среды (а именно,
>>  периодического обниливания ссылок на внешние модули\формы
>> в дизайнере), удобство работы "мышкой" полностью портится
>> необходимостью ведения борьбы с этими "фичами"

>Слышал про проблему. Но если в проекте держать открытым датамодуль, то >проблема исчезнет. По крайней мере видел этот способ решения

Если это не секрет, о каких "фичах" речь ? Вот уже сколько лет дружу с делфей, но не видел и даже не слышал.

ЗЫ. В целом ветка напоминает диспут о том, как монтировкой ковыряться в зубах. Как говорится, попутного ветра !

Вот уже сколько лет дружу с делфей, но не видел и даже не слышал.

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

> Если это не секрет, о каких "фичах" речь ? Вот уже сколько
> лет дружу с делфей, но не видел и даже не слышал.


А такая. Приходишь утром на работу. Запускаешь Delphi. Открываешь вчерашний проект (вчера перед выходом всё работало). Бах - а во всех ДБгридах пропали ссылки на датасорсы. И вообще, во всех ДБ-контролах пропали ссылки на датасорсы.
И если по какой-то причине не залил в CVS, то приходит .ОПА.

>Бах - а во всех ДБгридах пропали ссылки на датасорсы. И вообще, во всех ДБ-контролах >пропали ссылки на датасорсы.

Ух ты ! А как сделать такой веселый "Бах" ?
:)

> Ух ты ! А как сделать такой веселый "Бах" ?


А пёс его знает. Я серьёзно. Несколько раз натыкался. Хорошо ещё, если сразу заметил и нормальную версию из CVS выгрузил. А то бывает, что уже изменений навносил кучу.

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

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

Еще есть главный датамодуль, который содержит в себе соединения к разным БД, умеет работать со всякими сервисами типа нотификаций и конфигурирования и т.д.

А базовый датамодуль есть, но он общий для всех проектов и в нем прописана общая минимальная необходимая для всех проектов функциональность для главного датамодуля.

> У нас в проектах не принято выносить объекты данных в датамодули.
>  Всё живет непосредственно на фреймах, благо они, как правило,
>  небольшие.


Угу, я "опытным путём" к такой же идеологии пришёл.

аналогично.
все "визуализируемые" датасеты лежат там же, где и датааваре контролы.