ADOCommand или ADOQuery ?

← →
Al_tor (2006-08-11 14:23) [0]

Доброго времени суток!

Есть задача - выполнить несложный запрос (SELECT) к базе данных, при этом желательно минимизировать трафик. Что лучше применить ADOCommand или ADOQuery ? Или нет ни какой разницы?

← →
Dok (2006-08-11 14:41) [1]

минимизировать select! А для select использовать ADODataSet.

← →
Al_tor (2006-08-11 15:00) [2]

Минимизировать SELECT не получится - текст запроса, предоставлен организацией-хозяином базы. И уже оптимизирован

← →
Dok (2006-08-11 15:03) [3]

покажи пожста запросик.
значит не фитчить все записи - это ед. способ тогда.

← →
sniknik © (2006-08-11 15:14) [4]

> Что лучше применить ADOCommand или ADOQuery ? Или нет ни какой разницы?
разница есть, ADOCommand это основа, самая "легкая" часть ADO, он только и умеет команды(запросы) выполнять, если в нем выполняется запрос возвращающий рекордсет то его приходится передавать в ADODataSet т.к. нет методов работы с ним (навигации/обработки данных на клиенте/т.д.) поэтому его чаще используют для запросов невозвращающих рекордсетов...

для возвращающих используют ADODataSet т.к. в нем все это есть (в нем вообще есть все, что вообще есть... ;) в смысле для рекордсетов), + тотже ADOCommand как составная часть для работы с данными (просто "наружу" он не выведен).

а ADOQuery это некий "гибрид", аналог BDE-шной Query по свойствам (весьма приблизительный аналог, надо сказать), чтобы его сделать, существенно "порезали" возможности взятой основы (ADODataSet), прикрутили навеску (метод SQL) и вывели наружу внутренний ADOCommand (для ExecSql).

===============================
- мама смотри верблюд!
- я не верблюд, я лошадка, это меня в цирке так изуродовали...

и это еще ничего! вы посмотрите что они с ADOTable сделали. ;о)))

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

← →
sniknik © (2006-08-11 15:19) [5]

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

TADOCommand умеет то, чего не могут внучата легендарного TDataSet :))) Например, выполнять скрипты или возвращать несколько датасетов за раз

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

и скрипты может, единственное изза тойже специфики надо чтобы скрипт возвращал хоть один нормальный рекордсет... если набор кончится без такого, будет ексепт. который в принципе можно "погасить". ;) хотя и не нужно конечно, нужно соблюдать простое, четкое правило - возврашаемые рекордсеты команды в ADODataSet, невозвращаемые в ADOCommand. и все. все "тонкости"/исключения потом, когда лучше в механизме разберетесь.

ADOCommand или ADOQuery ? Найти похожие ветки