DBExpress.CleanupIntance;

← →
Jeer © (2008-09-15 17:28) [0]

Дернуло, чего-то, с 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

← →
Jeer © (2008-09-16 15:53) [1]

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

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

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

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

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

← →
Правильный$Вася (2008-09-16 16:04) [2]

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

← →
Jeer © (2008-09-16 16:09) [3]

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

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

← →
Правильный$Вася (2008-09-16 16:34) [4]

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

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

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

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

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

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

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

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

← →
Jeer © (2008-09-16 16:52) [5]

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

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

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

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

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

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

← →
jack128_ (2008-09-21 12:07) [6]

> CleanupInstance;

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

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

DBExpress.CleanupIntance; Найти похожие ветки