Свой TQuery

← →
avsam (2005-09-26 19:24) [0]

Пишу свой компонент TMyQuery. Мне нужно, чтоб он в зависимости от настроек, внутри создавал или TAdoQuery или TZQuery и имел все свойства обычного TQuery.
От какого предка лучше писать такой компонент.
На что нужно обратить внимание при работе в связке с TDataSource?

← →
sniknik © (2005-09-26 20:18) [1]

что такое TZQuery?

← →
avsam (2005-09-27 12:46) [2]

Query от ZeosLib. В принципе это не играет роли.
Задача состоит в том, чтоб создать полноценный TMyQuery, но доступ к базам данных внутри него будут осуществлять другие TQuery, созданные внутри в рантайме.

← →
ANB © (2005-09-27 12:48) [3]

> avsam (27.09.05 12:46) [2]
- а зачем ? Наличие TQuery в проекте потребует BDE. При каких условиях собираешься переключать ? Плюс разные движки => разные диалекты SQL.

← →
sniknik © (2005-09-27 13:32) [4]

ZeosLib для MSSQL делает "финт ушами" подключается через OLEDB провайдера MSSQL (хотя как как сышал это копоненты "прямого" доступа), т.е. также как ADO.
в итоге для него будет TZQuery будет = TAdoQuery (один из режимов), и получается делать ничего не надо... бери ADO(DataSet лучше) и успокойся на этом.
(зачем обьеденять если это одно и тоже?)

подробности как оно работает см. на сайте www.zeoslib.net когда он "встанет", пока "лежит" -
HOMEPAGE HACKED AND TEMPORARILY DOWN ------ The main ZeosLib product is a set of native datasets and database components for MySQL, PostgreSQL, Interbase, Firebird, MS SQL, Sybase, Oracle, DB/2 for Borland compilers such as Delphi, C++ Builder and Kyli

* Development Status: 5 - Production/Stable
* Intended Audience: Developers, System Administrators
* License: GNU General Public License (GPL), GNU Library or Lesser General Public License (LGPL)
* Operating System: All 32-bit MS Windows (95/98/NT/2000/XP), All POSIX (Linux/BSD/UNIX-like OSes), Linux
* Programming Language: C++, Delphi/Kylix
* Topic: Database Engines/Servers, Front-Ends
* Translations: English
* User Interface: Win32 (MS Windows), X Window System (X11)
http://sourceforge.net/projects/zeoslib/

← →
avsam (2005-09-27 14:32) [5]

Я хочу TMyQuery, которая может соединяться с разными базами данных.
TZQuery я использую для MySQL.
TOraQuery - для оракла.
TAdoQuery - для MSSQL.
Возможно добавится еще что-то.
Каким образом можно обернуть все эти компоненты в одну TMyQuery?

P.S. Разница в диалектах рещается путем преобразования SQL-команд "на лету".

← →
avsam © (2005-09-27 15:49) [6]

Приведу пример.

type
TMyQuery = class(TDataSet)
.......................
constructor TMyQuery.Create(AOwner: TComponent);
begin
inherited;
case RegistryOraSetup do
0: fOraQuery := TOraQuery.Create(Self);
1: fAdoQuery := TAdoQuery.Create(Self);
2: .........................
end;
end;

Дальше хочется, чтоб TMyQuery возвращал полностью набор данных, взятых с одного из подкомпонентов.
То есть, работал в связке с TDataSource и т.д.

← →
sniknik © (2005-09-27 16:09) [7]

имхо бредовая затея.

> То есть, работал в связке с TDataSource и т.д.
ну это можно, пример полноценного датасета (работает с DataSource) для текстового файла. сдесь.
(x):\Program Files\Borland\Delphi(x)\Demos\Db\TextData

← →
avsam © (2005-09-27 16:18) [8]

> имхо бредовая затея

Отчего?
Задача такая: есть софт, который работает с Ораклом. Необходимо для него добавить поддержку MSSQL, MySQL и еще некоторых баз данных.
Каким способом можно это решить?
Для клиентов, которые уже работают с системой все должно без изменений.

← →
Sergey13 © (2005-09-27 16:23) [9]

2[5] avsam (27.09.05 14:32)
>P.S. Разница в диалектах рещается путем преобразования SQL-команд "на лету".
Павлины говоришь? (с) т.Сухов
Ну-ну.
Как ты преобразуешь оракловый CONNECT BY например? Или Select From Select?

← →
sniknik © (2005-09-27 16:26) [10]

> Каким способом можно это решить?
ADO + нужный OLEDB/ODBC провайдер. все.
без использования особенностей языка конкретного сервера а только стандарта даже запросы будут в основном совпадать. а не будут то
> P.S. Разница в диалектах рещается путем преобразования SQL-команд "на лету".

← →
sniknik © (2005-09-27 16:28) [11]

кстати, даже стандарты бывают разные, один <> другому.

----------------------------------
не пытайтесь обьять необьятное.

← →
avsam © (2005-09-27 17:49) [12]

> ADO + нужный OLEDB/ODBC провайдер. все.

1. Что делать с существующими клиентами при обновлении программы.
2. OLEDB/ODBC работает для Оракла медленней, чем ODAC.

> не пытайтесь обьять необьятное

3. То есть это шефу сказать?

← →
Val © (2005-09-27 18:09) [13]

>avsam © (27.09.05 17:49)
зачем тут TMyQuery?
у этих квери есть общий предок? есть, так объявляйте переменную MyQuery типа предка и вызывайте Create нужного потомка использовав приведение к нему.

> 3. То есть это шефу сказать?

это чья-то проблема кроме вашей?
вы понимаете, сколько тонкостей придется учитывать для работы с тремя разными скл-серверами?

← →
Fay © (2005-09-27 18:13) [14]

AnyDAC пойдёт?
http://www.da-soft.com/

← →
sniknik © (2005-09-27 18:22) [15]

avsam © (27.09.05 17:49) [12]

> 1. Что делать с существующими клиентами при обновлении программы.
переводить на "новые рельсы"

> 2. OLEDB/ODBC работает для Оракла медленней, чем ODAC.
по твоей схеме с TMyQuery будет еще медленнее, гарантирую. (пример связи с датасорсе смотрел? думаеш все максимально оптимально реализуеш?)
и потом почему все говорят медленнее..., и никто из тех кто говорит нормально ADO не знает? это общественное мнение такое? где его формируют? ;о))

> 3. То есть это шефу сказать?
в том числе, если его регулярно наполеоновские планы посещают.

Val © (27.09.05 18:09) [13]
> для работы с тремя разными скл-серверами?
3 не проблема, отследить можно. (есть работающая прога сервер на выбор один из - Access, MSSQL, IB 6.5 (и выше), нормально работает, без проблем)

это если пытаются "для всех" написать, вот это проблема.

← →
Val © (2005-09-27 18:36) [16]

>sniknik © (27.09.05 18:22)
я не сказал, что нельзя. сложно.

← →
avsam © (2005-09-27 19:26) [17]

> у этих квери есть общий предок? есть, так объявляйте переменную
> MyQuery типа предка и вызывайте Create нужного потомка использовав
> приведение к нему.

Можно об этом поподробней?

2 sniknik:

> > 1. Что делать с существующими клиентами при обновлении
> программы.
> переводить на "новые рельсы"

Об этом можно забыть. Программа находится в разных странах, на разных континентах. "Переводить" обойдется дороже, чем все заново создать.

← →
sniknik © (2005-09-27 21:50) [18]

> "Переводить" обойдется дороже, чем все заново создать.
ну если ты собираешся лично езьдить и и переставлять. ;) то да.

но вот например когда ты антивирус или еще лучше винду обновляеш... к тебе же никто из мелкософта не приезжает (или ??? ;)... а замены делаются гораздо более сложные чем смена одной программы с установкой нужного провайдера.

← →
roottim © (2005-09-28 08:27) [19]

А ZeosLib в виде TZQuery разве не ревлизует то что тебе надо ?

← →
АлеКо (2005-09-28 08:50) [20]

Может проще будет использовать универсальный язык данных, например XML.
Современные системы более-менее имеют поддержку этой технологии.

← →
ZeroDivide © (2005-09-28 13:14) [21]

Подобная унификация неизбежно приведет к существенному ограничению использумого SQL-диалекта до того минимума, который бы поддерживался всеми СУБД. А так ли оно надо? В конечном счете может оказаться что для быстоты доступа и даже для скорости разработки, выгоднее будет иметь просто еще одну (или неск.) версию (часть модулей) заточенных под конкретную СУБД. И выпускать соответственно разные билды для разных СУБД.

Может проще (и грамотнее) огранизовать управление проектом имеющим несколько видов билдов?

← →
ZeroDivide © (2005-09-28 13:37) [22]

Хотя у нас у самих и написан такой механизм, но, если честно, он не так чтобы юзается... Точнее юзается, но только в 98% случаев для доступа к одной БД.

some source (modified :) ):

FindDBAdapter(DataSet).ExecuteQuery(QueryStr); ... function FindDBAdapter(DataSet: TxDataSet): TDBAdapter; begin Result := DBAdapters.FindDBAdapter(DataSet); end; .... function TDBAdaptersList.FindDBAdapter(DataSet: TxDataSet): TDBAdapter; var i: Integer; begin Result := nil; for i := 0 to FList.Count - 1 do if (FList[i] as TDataSetAdapterRec).DataSetClass = DataSet.ClassType then begin Result := (FList[i] as TDataSetAdapterRec).DBAdapter; Break; end; end; *******************

Ну и соответственно написан базовый класс TDBAdapter (почти полностью виртуальный) и несколько его потомков (напр. TOracleDBAdapter, TFireBirdDBAdapter) реализующих собственно методы типа CreateInsertStatement и ExecuteQuery (в диалекте нужной СУБД)... На самом деле этих методов куча, но надеюсь я смысл донес.

.... А ну да, а потом еще пришлось переписать, точнее написать заново все VCL DB компоненты. Но это уже другая тема.

Короче куча сил, времени и вообще... И в итоге все равно некоторые специфические вещи приходится писать для конкретной СУБД напрямую...

В общем-то можно собрать проект под одну БД и под другую, но чтоб под всеми сразу все работало... эээ... нет... нафиг, извините. Все таки лучше [21]

> ну если ты собираешся лично езьдить и и переставлять. ;)
> то да.

А кто должен это делать? Либо кто-то из нас (что довольно дорого), либо нанимать фирму поблизости, что тоже недешево.
Клиенты сами это делать не хотят и не будут.
Платить за это они тоже не хотят и не будут (в принципе логично).

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

С майкоросфта не приезжают. А приезжает работник другой фирмы и это все ставит. Что тут неправильно?
Или ты на фирме и программер и админ и секретарь?

[23] avsam © (28.09.05 14:50)
А кто должен это делать? Либо кто-то из нас (что довольно дорого), либо нанимать фирму поблизости, что тоже недешево.
Клиенты сами это делать не хотят и не будут.

Что-то я не понял. А зачем вы вообще делаете новую версию, если ее ставить у клиентов все равно никто не будет?

Странно, что вроде никто еще не упомянул трехзвенку.

> Платить за это они тоже не хотят и не будут (в принципе логично).
если покупали программу то нелогично, апдейты как бы подразумеваются. если же они у вас на обслуживании/поддержке то цена выезда должна была быть включена в договор обслуживания. (если менеджер не "лоханулся")

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

> С майкоросфта не приезжают. А приезжает работник другой фирмы и это все ставит. Что тут неправильно?
оппа!?? ;о)) выбор пункта меню (нажатие 1 кнопки) в интернет эксплорере и дальнейшее подтверждение выбора делаются специалистом сторонней фирмы?
????
открою вам глаза. они просто "бабки с вас стригут" практически ни за что. ;)

> Или ты на фирме и программер и админ и секретарь?
причем сдесь секретарь? хотя и секратари у нас эту кнопку сами нажимают... (а была одна, сама себе винду поставила(!), сам не ожидал от секретаря ;), когда компы на новые меняли а админа не было по какойто причине)

Sergey13 © (28.09.05 15:53) [25]
> Странно, что вроде никто еще не упомянул трехзвенку.
хочеш поговорить об этом? ;о))

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

2[27] sniknik © (28.09.05 16:02)
> что нового даст трехзвенка, в плане работы с несколькими серверами
Для каждого сервера БД свой сервер приложений естественно нужен. Что даст? Независимость клиента например.
Я не пропагандирую 3х звенку. Просто предлагаю рассмотреть как вариант. ИМХО не хуже чем самописный кверик где "Разница в диалектах рещается путем преобразования SQL-команд "на лету"."

ИМХО, геморрой страшнейший.

Migrating это вообще задачи класса-люкс, и так сналету сделать и то и другое. Не уверен.

А по вопросу можно предложить следюущее. Везде использовать TDataset, просто в нужном месте создавать нужного потомка, с последующим приведением типов его использовать.

Надеюсь понятно изложылсо.

> оппа!?? ;о)) выбор пункта меню (нажатие 1 кнопки) в интернет
> эксплорере и дальнейшее подтверждение выбора делаются специалистом
> сторонней фирмы?
> ????

:) Это у вас все просто. Тут немного сложнее.
1. Компов может быть и 50 штук (на каждом оп-оп не получится).
2. Компы могут быть на значительном расстоянии от сервера (400-500 км). Ладно, для этого есть удаленный доступ.
3. Мой час работы для фирмы стоит больше, чем час работы работника со сторонней фирмы.
4. Не вижу смысла тут оффтопик разводить. Будет желание дальше побеседовать - мое мыло: avsam@web.de

> если же они у вас на обслуживании/поддержке то цена выезда должна была > быть включена в договор обслуживания. (если менеджер не "лоханулся")

:) Где это цена выезда включена в договор? Если бы так, нас таскали бы клиенты к себе каждую неделю. Сколько билет на самолет стоит? А гостинница, суточные и т.д. Это не в Черемушки на маршрутке съездить.
А какого менеджера ты имел ввиду? Нашего, что продавал или ихнего, что покупал?

> А по вопросу можно предложить следюущее. Везде использовать
> TDataset, просто в нужном месте создавать нужного потомка,
> с последующим приведением типов его использовать.

Спасибо за ответ. Скорее всего так и буду пробовать.
И похоже, это самый оптимальный способ

Свой TQuery Найти похожие ветки