"Kovalenko Dmitry" ...
>
> > > Старые алгоритмы вычисления RowsAffected не
> > > рюхают exec_stmt или как там его для
> > > хранимых процедур называют - не помню.
> >
> > Я знаю только один 'алгоритм' вычисления RowsAffected.
> > И его можно применять к любому отпрепаренному стейтменту,
> > независимо от его типа.
>
> Так, давай поясню.
>
> Мне нужно получать RowsAffected только для
> INSERT/UPDATE/DELETE
Я бы сказал, что тебе нужно получать RowsAffected
а) когда попросит юзер - тут нужно возвращать святую правду
и ничего кроме правды
б) когда ты за него делал аналог INSERT/UPDATE/DELETE - тут ты
знаешь, что ты собирался делать и возвращать нужно соответствующее
значение
Что я упустил ?
> Для остальных - алгоритм должен вернуть -1.
Это не понято
> Старый алгоритм получает
> тип запроса и количество
> добавленных/обновленных/удалаенных
> записей. В зависимости от типа мы
> выбирали не более одного из этих трех
> чисел - остальные игнорировались
Не нравится
> Что мы имеем с RowsAffected для INSERT...RETURNING?
Да-да - что мы имеем ? :)
> Мы имеем модификацию алгоритма,
> который теперь кладет на тип запроса
> (либо начинает поддерживать
> isc_info_sql_stmt_exec_procedure) и складывает все три
> числа.
Зачем он их складывает ???
> Если мы выполним запрос с хранимой
> процедурой (isc_info_sql_stmt_exec_procedure) - такой
> алгоритм сработает и вернет сумму
> чисел. Б....я буду - у меня для таких
> запросов получался ноль. А мне ноль не
> нужен, мне нужен -1.
Сервер -1 никогда не возвращает. Я вообще не понимаю -
откуда у тебя такое требование.
> > > А insert ... returning - теперь у нас объявлен
> > > как хранимая процедура.
> >
> > И как это мешает получить RowsAffected ?
>
> Начинает неправильно считаться RowsAffected
> для хранимых процедур.
Считай правильно и никого не вводи в заблуждение. Для процедуры,
вообще говоря, понятия абстрактного RowsAffected не существует.
--
Хорсун Влад
PS как вариант : если у тебя запрос вызывался в качестве INSERT,
возвращай клиенту кол-во вставленных строк и т.д.
