Зачем очистка параметров?...

← →
databaser (2007-03-10 09:53) [0]

При установке CommandText в TADODataSet"e имеем следующее:

if (CommandType = cmdText) and (Value <> "") and ParamCheck then InitParameters else begin CommandObject.CommandText := Value; if not Loading then Parameters.Clear; // зачем?! end; // (с) Borland

Использую я cmdStoredProc. В итоге при смене имени процедуры имею очистку параметров. Делать "бэкап" оных перед присвоением и восстанавливать после? Писать наследника и перекрывать AssignCommandText - изврат полный.

← →
DrPass © (2007-03-10 11:36) [1]

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

← →
databaser (2007-03-10 11:58) [2]

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

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

var List: TParameters; begin ... List := TParameters.Create(dsBase{nil}, TParameter); List.Assign(dsBase.Parameters); dsBase.CommandText := "MY_STORED_PROC"; dsBase.Parameters.Assign(List); List.Free; ... end;

Натыкаюсь на AV (все проверил вроде, так и не понял откуда берется).

← →
Desdechado © (2007-03-10 18:35) [3]

> это, имхо, удобнее генерации параметров в run-time для каждой
> sp в отдельности.
Удобнее пользоваться встроенной автосчитывалкой параметров из БД, которая срабатывает при присваивании имени процедуры.

← →
databaser (2007-03-10 22:14) [4]

Desdechado © (10.03.07 18:35) [3]
поясните пожалуйста! как это работает? в справке не видел подобного. это действительно было бы удобно.

Я видел как можно получить параметры через ParseSQL, но ведь это немного не то (я имею в виду в моем случае использования StoredProc)

← →
Johnmen © (2007-03-11 01:35) [5]

Desdechado © имел в виду TADOStoredProc.

← →
databaser (2007-03-11 09:58) [6]

Johnmen © (11.03.07 01:35) [5]
Спасибо, разобрался.

Посмотрел на поведение TADODataSet, TADOStoredProc и задался вопросом. Что оптимальнее использовать 1 DataSet и каждый раз закрывать -> указывать имя процедуры -> открывать или же использовать множество DataSet"ов, каждый из которых уже заточен под свою задачу?

Просто посмотрел сколько времени тратится на Close. Проверял в цикле (2000 раз) на одном из параметризированных запросов (меняя параметр, понятное дело). Вариант со сменой процедур и соответственно Close - 25 секунд(!), вариант "под ключ" < 100 мс(!).

Все зависит от задачи. Если ты их не будешь вызывать сотни раз и заботишься о ресурсах клиентской части, то достаточно одного компонента. Если есть какие-то взаимосвязи, то бывает необходимо несколько одновременно. Но на каждый запрос лепить свой - глупость, имхо.

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

← →
databaser (2007-03-11 22:32) [8]

Desdechado © (11.03.07 18:08) [7]
Я прошу прощение, можно ли с вами каким-либо образом связаться вне форума? Просто есть пара небольших вопросов, которые не хотелось бы задавать в контексте форума по ряду причин. Лучше, если бы это был ICQ. Обещаю не отнять много времени.

С этой веткой можно завязывать. Остальные продолжим.

Johnmen © (11.03.07 01:35) [5]
Я не знаток ADO, но в дизайне у ADODataset при CommandType=cmdStoredProc параметры подчитываются автоматом. Видимо, можно настроить это и в runtime.

databaser (11.03.07 22:32) [8]
Ищущий да обрящет. Однако я предпочитаю форум.

Зачем очистка параметров?... Найти похожие ветки