Скачать: CL | DM;

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

← →
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 мс(!).

---

← →
Desdechado ©   (2007-03-11 18:08) [7]

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

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

---

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

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

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

---

← →
Desdechado ©   (2007-03-12 11:42) [9]

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

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

---

Страницы: 1 вся ветка

Скачать: CL | DM;



Память: 0.47 MB
Время: 0.03 c