Дернуло, чего-то, с DBExpress позаниматься и обнаружил занятную фишку.
Если допустить автоматическое заполнение параметров TSQLConnection и будет там прописан текущий сервер, то простая замена на другой сервер не срабатывает
Params.Values['HostName'] := srvName;

Приходится обязательно перепрописывать во так

 with dm.dmMain do begin
   with conSource do begin
     if not Connected then begin
     CleanupInstance;
       ConnectionName  := 'RIAS';
       DriverName := 'MSSQL';
       GetDriverFunc := 'getSQLDriverMSSQL';
       LibraryName := 'dbexpmss.dll';
       VendorLib := 'oledb';

       Params.BeginUpdate;
       Params.Values['HostName'] := srvName;
       Params.Values['DataBase'] := DBName;
       Params.EndUpdate;
     end; // if
   end;   // with conSource

В общем, пошупал DBExpress и убедился, что раньше лучше оно было :))

Собственно, стоит задачка ухода с BDE+ODBC, но эта связка работает всяко лучше, чем DB Express и шустрее точно.

Почему не "прыгнуть" явно на IB или MS... ?

Приложение ( класса OLAP, а точнее - ROLAP ) должно работать, по выбору пользователя, с разными БД, обслуживаемыми разными же серверами.
На сегодняшний день их три по типу и много больше по количеству: IB(FB), MSSQL, Oracle и поддерживать синхронно бизнес-процессы на N-ом количестве SQL-платформ никому такая "умная" задача в голову не залезает :)

Иех..., тоска c DBExpress, на ADO (OLE DB) что-ли:(

года 3 поддерживал бизнес-процессы на комбинации FB1.5+Ora9.2
и именно через dbExpress
вполне сносно, если не учитывать значительный объем репродуцирования серверной логики
никаких особых клинов не встретил, не считая довольно слабого комплектного драйвера для оракла

Да я не говорю, что не сносно..
"Обработка" показателей по однотипному алгоритму идет на ODBC 15 сек, что терпимо для пользователя и в два раза больше на dbEpress :((

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

> "Обработка" показателей

выноси на сервер

> скоростной режим с TSQLQuery не катит

забудь, используй SQLDataset

>  не катит, т.к. однонаправленный курсор

во многих случаях это большой плюс

> приходится задействовать simpledataset, что раздувает некрасиво
> код и тормозит

попробуй ClientDataSet + DataProvider
если не тягать на клиента километры данных, все очень пристойно

>
> > "Обработка" показателей
>
> выноси на сервер
>


Низя, это ROLAP, во-первых, во-вторых никто не будет заниматься репликацией бизнес-логики по серверам.


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


К сожалению, для иерархических справочников это "минус" принципиальный.
Заниматься First/Next  вместо Locate - не кузяво.


> попробуй ClientDataSet + DataProvider
> если не тягать на клиента километры данных, все очень пристойно
>


Это не принципиально - один фиг по скорости, что и simple*

>      CleanupInstance;

Это ты жестко с ним..
Ты в курсе, что этот метод делает???

>> скоростной режим с TSQLQuery не катит
> забудь, используй SQLDataset
почему? я вот понимаю почему в ADO имеет смысл отказаться от TADOQuery, не передает, а коверкает идеологию самого ADO, а здесь какой смысл, они что в DBExpress тоже чтото им исковеркали? или просто "за компанию"?