Так все таки использовать ли TADOCommand всегда?

← →
Kolan © (2007-12-21 11:05) [0]

И почему?
В правки сказано что
For SQL statements that return a result set, TADODataSet, TADOQuery, or TADOStoredProc is better suited.
И что
To use that recordset, however, you will need a separate ADO dataset component.

Вроде бы лень. Использовать separate ADO dataset&#133

Почему бы не воспользоваться TADOQuery для получения наборов данных?

← →
Правильный_Вася (2007-12-21 11:07) [1]

> TADODataSet

это нормально, как и Command
остальное - под(д)елки

← →
DVM © (2007-12-21 11:10) [2]

> Так все таки использовать ли TADOCommand всегда?

всегда не стоит

Если предполагается получение записей после выполнения запроса, следует использовать TAdoDataSet, если нет, то TAdoCommand

TAdoTable, TAdoQuery - это наследие BDE и использовать их для работы с ADO нецелесообразно.

← →
Kolan © (2007-12-21 11:17) [3]

Так правильно?

var DataSet: TADODataSet; begin if Assigned(MustBeDBVersion) then begin DataSet := TADODataSet.Create(nil); try with DataSet do begin Connection := Connection; CommandText := "SELECT * FROM sldiagn"; Open; Result := not Eof; end; finally DataSet.Close; DataSet.Free; end; end;

← →
DVM © (2007-12-21 11:20) [4]

> Result := not Eof;

это что?

← →
Kolan © (2007-12-21 11:23) [5]

> это что?

Ну типа вернулось что то или нет, то етсь пустой датасет или нет&#133

Eof Indicates whether a dataset is positioned at the last record.

← →
DVM © (2007-12-21 11:25) [6]

> Ну типа вернулось что то или нет, то етсь пустой датасет
> или нет…

Cделай на всяк случай First перед проверкой на Eof. Может оно и лишнее, но логичнее.

← →
sniknik © (2007-12-21 11:25) [7]

> Так все таки использовать ли TADOCommand всегда?
я бы сказал не так, а от обратного -
никогда не использовать TADOTable, TADOQuery или TADOStoredProc. а уж что использовать это на твое усмотрение... смотря что необходимо сделать.

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

основная идея ADO (имхо) это четкость деления запросов по типу - возвращающие данные и управляющие(командные). для возвращающих используется TADODataSet, для командных TADOCommand, очень просто. легко для обучения/понимания. (не, есть конечно исключения и можно использовать не совсем так, но это потом, после понимания как оно устроено(/задумано))

← →
Ega23 © (2007-12-21 11:28) [8]

> Ну типа вернулось что то или нет, то етсь пустой датасет
> или нет…

TDataSet.IsEmpty + F1

← →
Kolan © (2007-12-21 11:34) [9]

> нравится  пользуйся.

Не я хочу как лучьше, я не так давно занимаюсь БД и АДО, чтобы мне что-то наравилось или нет.

Короче вывод:
Для SELECT пользую TADODataSet
Для INSER UPDATE &#133 пользую TADOCommand.

И это самый good rule of thumb, так?

> TDataSet.IsEmpty + F1

Ок, а в остальном норм?

← →
Kolan © (2007-12-21 11:37) [10]

А вместо FieldByName использовать FieldValues?

← →
DVM © (2007-12-21 11:37) [11]

> Ок, а в остальном норм?

можно и без внешнего Connection сделать. У TAdoDataSet есть свойство ConnectionString, он сам не явно создаст TAdoConnection. Тогда функция станет как бы более автономной. Но тут, конечно по задаче надо смотреть.

← →
DVM © (2007-12-21 11:38) [12]

> А вместо FieldByName использовать FieldValues?

где использовать?

← →
DVM © (2007-12-21 11:43) [13]

> Kolan ©

Кстати, если цель данного кода - только узнать не пуст ли набор данных, может и запрос сделать, например "SELECT ID FROM sldiagn", где, скажем ID это первое поле с ключом. ИМХО это должно облегчить код.

← →
Sergey13 © (2007-12-21 11:44) [14]

> [13] DVM © (21.12.07 11:43)

Уж может тогда просто count запросить?

← →
Kolan © (2007-12-21 11:45) [15]

> где использовать?

Ну вот я выполнил(Open) запрос

Как теперь зделать то, что я рань ше делал так:

Int := Query.FieldByName("ID").AsInteger;

← →
sniknik © (2007-12-21 11:46) [16]

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

должно быть так
var RAff: Integer; begin if Assigned(MustBeDBVersion) then //не знаю зачем это, но оставим... begin Connection.Execute("SELECT TOP 1 1 FROM sldiagn", RAff); Result := RAff = 1; end; end;
функция будет делать тоже самое но менее "напряжно" для всех.

← →
sniknik © (2007-12-21 11:48) [17]

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

← →
Kolan © (2007-12-21 11:49) [18]

> (идеологически ;),

Ок, учту. Я вопрошал про синтаксис. В основном.

Connection.Execute();
Нафиг тогда вообще TADOCommand? Если можно так?

← →
DVM © (2007-12-21 11:50) [19]

> Уж может тогда просто count запросить?

действительно.

> Как теперь зделать то, что я рань ше делал так:
>
> Int := Query.FieldByName("ID").AsInteger;

все остается так же.

← →
Kolan © (2007-12-21 11:51) [20]

Нафиг тогда вообще TADOCommand? Если можно так?
> а это уже баг

Я выдрал кусок просто для вопроса, сверху

begin Result := False; if Assigned(MustBeDBVersion) then begin

Так ессно&#133

← →
DVM © (2007-12-21 11:51) [21]

> Нафиг тогда вообще TADOCommand? Если можно так?

куда результат то получать будешь? записи то есть.

← →
Kolan © (2007-12-21 11:52) [22]

> все остается так же.

Млин это просто D7 внутри with не подсказал&#133

Все  все уяснил  вопрос снят&#133

← →
sniknik © (2007-12-21 12:03) [23]

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

← →
Kolan © (2007-12-21 12:05) [24]

Все ясно, благодарю за обсуждение.

← →
Ega23 © (2007-12-21 12:22) [25]

> sniknik © (21.12.07 11:25) [7]

Коля, ещё раз тебе БОЛЬШОЕ СПАСИБО!!!
Увидел код в [7] и понял как изящно разрешить проблему, которая у меня решалась достаточно криво.

Увидимся в реале - с меня пиво.

← →
DrPass © (2007-12-21 13:01) [26]

И все-таки объясните, кто придумал чушь про вред TADOQuery TADOTable и какие-либо преимущества TADODataSet? Посмотрите исходники - это фактически один и тот же класс.

> И все-таки объясните, кто придумал чушь про вред TADOQuery
> TADOTable и какие-либо преимущества TADODataSet? Посмотрите
> исходники - это фактически один и тот же класс.

И все-таки объясните, кто придумал чушь про вред TMemo и какие-либо преимущества TEdit? Посмотрите исходники - это фактически один и тот же класс (TCustomEdit).

> И все-таки объясните, кто придумал чушь про вред ...
вот объясни лучше ему, что не вред...
http://delphimaster.net/view/2-1197977411/
это переодически постоянно возникающий вопрос... (и кстати гдето в чемто действия автора логичны, команду же сначала надо выполнить, а потом если есть результат открыть, не было бы результата не открываем. ну логично же!? поставте себя на место только только начинающего, неглупого, но с нулевыми знаниями по теме...)

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

p.s. очередной "бисер" имхо. "рожденный ползать, понять не может!" © между двух стульев.

← →
b z (2007-12-21 13:26) [29]

кое что поясняется
ADOConnection The ADOConnection component plays a role very similar to that of the TDatabase class, in that it provides information that can be used by two or more components to connect to a common data source. This connection information is provided by the ConnectionString property, which includes information about which OLE DB provider to use, the user name, password, data source, and any other information required to connect to the data. The TDataSet descendants do not actually need an ADOConnection, although you will nearly always use one. Each of the components that appear in the preceding figure has their own ConnectionString property, which can be configured to use a particular data source. However, by using a ADOConnection to store the connection string, individual ADOCommand or dataset components can simply point to the ADOConnection, instead of including their own connection string. If you are familiar with the ADO interface, you will be interested to learn that the ADOConnection component surfaces a public ConnectionObject property, giving you direct access to the encapsulated connection object. ADOCommand The ADOCommand component encapsulates an ADO command object, which can be used to execute SQL statements, including data definition language (DDL) statements such as CREATE TABLE or ALTER INDEX, as well as execute stored procedures that do not return a result set. If you are already familiar with the ADO command object, you will find that the ADOCommand component sports the same programming interface as that object. One notable benefit of the ADOCommand object is that you can use it to return a Recordset (a pointer to one or more records from a data source). After executing an ADOCommand to return a Recordset, set an ADODataSet’s public Recordset property to the corresponding ADOCommand. TDataSet Descendants The VCL"s ADO components include four TDataSet descendants: TADODataSet, TADOTable, TADOQuyery, and TADOStoredProc. TADODataSet is the most flexible, capable of returning the records of a table or result set of a SQL SELECT statement. You cannot, however, use a TADODataSet to execute SQL statements that do not return a result set. The TADOTable, TADOQuery, and TADOStoredProc components are designed to share an interface similar to their BDE counterparts: TTable, TQuery, and TStoredProc, respectively. For DDL and DML statements that do not return a result set, use the TADOQuery or TADOCommand component.

> Ega23 © (21.12.07 13:19) [27]

Неудачный пример. Есть один-единственный СОМ-объект, Recordset. Эти три класса, TADOQuery, TADOTable и TADODataSet - это фактически одинаковые оболочки над ним (ну, TADOTable имеет небольшие отличия). Смысл этого "разнообразия" скорее в том, чтобы облегчить переносимость уже написанного кода. Т.к. если у человека есть MyQuery.SQL.Text:= ..., ему будет удобнее так и оставить, а не переделывать под TADODataSet. При этом оба датасета будут работать совершенно одинаково, отличаясь только названиями пары свойств.
Разве я не прав?

> но! идеология у него от другого, BDE-шного файл сервера
> - открытия таблиц(! не запрос на данные)

Дык, это ж не компонент виноват, а программист. Какая разница, где глупости делать - тянуть большую таблицу через TADOTable или написать select * from that_table в ADODataSet?
А как локальный кеш для небольших справочников ИМХО TADOTable очень даже неплохо смотрится.

> кто придумал
раз интересно, это был я... ну не то что я был единственным до этого додумавшимся, или первым, нет, наверняка были еще и до меня. но это было мое самостоятельное(не прочитанное гденибудь) решение, в самом начале работы с ADO (2000г), решение по массе (тогда аналогичного рода вопросов [28]) проблем вываливаемых на сайт было не в пример больше. проблем изза, маленькой, неуловимой некоторыми разнице...
вот тогда я это и придумал и начал "нести в массы", на этот же сайт, и комуто это даже помогло.

> Дык, это ж не компонент виноват, а программист.
программист которому дали "типа замену" для перехода. т.е. фактически обманули. если бы не это то поддержал бы его виновность на все 100%.

> А как локальный кеш для небольших справочников ИМХО TADOTable очень даже неплохо смотрится.
почему не ADODataSet?
посмотри в исходники это практически один .... и т.д.
ради одного "протянутого за уши" варианта использования морочить головы миллионам?... нда .уж.

p.p.s. end.

> Увидимся в реале  с меня пиво.

Отметил, чтобы не забыть :). Хорошо вообще  сам ниче незнаю, спросил мне ответили, решил свою траблу, да еще и пиво :), живем&#133

> sniknik © (21.12.07 13:40) [31]

Можно без end"ов обойтись? Т.к. это похоже на "я не хочу слышать никаких аргументов, т.к. я и только я прав" :)
Я еще хочу позанудствовать, т.к. вопрос не такой уж и бестолковый - мне приходилось видеть таких вот "просветленных" начальников, которые благодаря этому совету заставляли подчиненных переделывать кучу кода.
Да хотя бы давай откинем в сторону TADOTable, тут я даже согласен - ее особенности "неинтуитивны", и я ее так, до кучи привел. А TADOQuery хотя бы причем, можешь мне внятно объяснить?

> [33] DrPass © (21.12.07 13:51)

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

смысла в споре нет...

> Отметил, чтобы не забыть :). Хорошо вообще — сам ниче незнаю,
> спросил мне ответили, решил свою траблу, да еще и пиво
> :), живем…

Эта... Не хочу тебя обидеть, но пиво, вообще-то, обещано sniknik ©. :)
За ответ в [16]. :)
Просто он - тоже Коля... :)))

> А TADOQuery хотя бы причем, можешь мне внятно объяснить?
а я тебе должен? хотя бы и невнятно.
или скажем по другому, ты способен понять? услышать?

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

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

Так все таки использовать ли TADOCommand всегда? Найти похожие ветки