Не выполняется insert в ХП, вызываемой из клиентского приложения

← →
Calm © (2002-12-17 12:55) [0]

Имеется хранимая процедура, которая выполняется два основных действия:
1. Добавляет в таблицу запись
2. Делает выборку.
В IBExpert процедура работает отлично.

В клиенстком приложении беру компонент MyDS:TpFIBDataSet и в SQLs.SelectSQL пишу очень простой запросец:
select * from MyStoredProc(:prm1, :prm2);
Компонент говорит, что SQL правильный ("SQL is correct")
Естественно, у компонента установлены свойства DataBase и DefaultTransaction.

Что выполнить требующеся действие делаю так:
MyDS.close; MyDS.ParamByName("prm1").As..// присваиваю параметрам значенияЗначения присваиваются вполне правильные, т.к. эти же параметры отлично проходят, если вызвать ХП из IBExpert"а.
Далее
MyDS.Open;

Процедура возвращает выборку. Причем правильно. Значение генератора ID таблицы, в которую добавляется запись инкрементируется (правильно!). Но... запись в таблицу не добавляется. Почему?

Заранее спасибо за советы

Использую FIBPlus 4.7

← →
Prooksius © (2002-12-17 13:01) [1]

Может, ты ее просто не видишь (другая транзакция)?

← →
Alexandr © (2002-12-17 13:07) [2]

commit

← →
Calm © (2002-12-17 13:08) [3]

Может, но...
Я уже пробовал и Delphi и IBExpert выгружать и заново запускать. Все равно не видно...

Последовательность действий такова:
1. Запускаю клиентское приложение, выполняю запрос.
2. Закрываю клиента. В design-time Delphi подключения к БД нет.
3. Открываю IBExpert
4. Не вижу записи, которая должна быть добавлена

Так, что вроде бы транзакции ни при чем...

← →
Calm © (2002-12-17 13:09) [4]

> Alexandr © (17.12.02 13:07)
> commit

Это что? Куда?

← →
Prooksius © (2002-12-17 13:10) [5]

Давай текст процедуры

← →
Prooksius © (2002-12-17 13:15) [6]

Alexandr © (17.12.02 13:07) возможно прав.
Как ты завершаешь работу с транзакцией, в которой ты это делаешь?
Надо Commit. Иначе данные не инсертнутся.

← →
Calm © (2002-12-17 13:15) [7]

Вот процедурка

CREATE PROCEDURE ADD_TASK_CASCAD (
AHHOID integer,
ACIID integer,
AVFLOAT DOUBLE PRECISION,
AROOTID INTEGER,
AIDATE DATE,
ADATEPOINTID integer)
RETURNS (
OUT_TASKID INTEGER,
OUT_SUPPORTCIID INTEGER)
AS
begin

insert into Task (HHO, CtrlItem, CtrlItemKindCode, VFloat, IDate, ActiveStatus, Root, DatePoint)
values (:ahhoid, :aciid, 0, :vfloat, :aidate, 1, :arootid, :adatepointid);

/* Сначала нужно вернуть id только что добавленной записи в Task */
out_taskid=gen_id(gen__task, 0);
out_supportciid=:lciid;
suspend;

for select GSCI.out_CIID
from get_supportctrlitem_ext(:aciid) GSCI
into :out_supportciid
do begin
suspend;
end
end

Итак, в IBEXpert"t работает как нужно.
Из клиентского приложения - выборка возвращается правильная, а запись не добавляется. Хотя генератор изменяется.

← →
Alexandr © (2002-12-17 13:17) [8]

и все-таки commit.

← →
Calm © (2002-12-17 13:17) [9]

> Prooksius © (17.12.02 13:15)
> Alexandr © (17.12.02 13:07) возможно прав.
> Как ты завершаешь работу с транзакцией, в которой ты это
> делаешь?

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

← →
Calm © (2002-12-17 13:18) [10]

> Alexandr © (17.12.02 13:17)
> и все-таки commit.

Не сочти за труд - поясни немного

← →
Alexandr © (2002-12-17 13:22) [11]

MyDS.Close;
MyDS.Transaction.Commit;

Короче, читай доку, читай www.fiblus.com.ua
и все станет ясно

← →
Calm © (2002-12-17 13:26) [12]

2 Alexandr и Prooksius: Спасибо! Заработало :))

← →
Prooksius © (2002-12-17 13:26) [13]

Лучше явно работать с транзакциями. Стартуешь, комитишь при отсутствии ошибок, откатываешь при ошибках. Все видно.
Похоже, при закрытии программы у тебя происходит роллбэк.
Не знаю, как ведет себя FIBPlus при неявной работе с транз. - так с ними не работаю.
У pFIBDataBase есть эвент BeforeEndTransaction. Поиграйся с параметрами.

P.S. Генератор работает вне транзакций и от них не зависит.

← →
Calm © (2002-12-17 13:41) [14]

Делаю MyDS.Transaction.Commint, после чего добавленная запись видна, но вот выборка, сделанная процедурой, не отображается в гриде.
ПОлучается нельзя в одной хранимой процедуре одновременно осуществить добавление и выборку?

ЗЫ а ссылочка www.fiblus.com.ua метрвая

← →
Alexandr © (2002-12-17 13:46) [15]

1) fibplus.com.ua
2) Конечно, изврат ты какой-то придумал...

← →
Fareader © (2002-12-17 13:49) [16]

ЗЫ а ссылочка www.fiblus.com.ua метрвая

Надо www.fibplus.com.ua

← →
Calm © (2002-12-17 13:51) [17]

Спасибо.
А ссылочку, я конечно, проглядел - скопировал неглядя

← →
Johnmen © (2002-12-17 13:54) [18]

CommitRetaining

← →
Calm © (2002-12-17 14:06) [19]

2 Johnmen © Вот за это спасибо :)

← →
Alexandr © (2002-12-17 14:16) [20]

за что? за commitRetaining?
это скрытые грабли!
Привыкнешь - ломка будет очень тяжелой. Помяни мое слово...

← →
Prooksius © (2002-12-17 14:29) [21]

2 Alexandr © (17.12.02 14:16)
Согласен.
Как-то пришлось перелить данные из *,txt в *,gdb.
В базе были обычные поля и блоб.
В Query.SQL обычный запрос на insert.
Транзакцию завершал CommitRetaining.
После вставки около 10000 записей - жуткие тормоза все намертво повисало (IB server где-то не освобождал память)
Поменял на Commit + StartTransaction - все заработало.

← →
Johnmen © (2002-12-17 14:29) [22]

>Alexandr © (17.12.02 14:16)

Благодарил он меня действительно зря, т.к. это есть в хелпе...
А вот насчет <это скрытые грабли!> можно подробнее ?
А то я привык, а ломки все нет :))) Может еще рано ? :)))

← →
Johnmen © (2002-12-17 14:36) [23]

>Prooksius © (17.12.02 14:29)

Ситуация принципиально другая...

← →
Alexandr © (2002-12-17 14:37) [24]

ну попробуй как Prooksius © (17.12.02 14:29)
раскопай грабли, они тебя по лбу и стукнут...
Я не помнб точно, правили ли это в Firebird, но на Interbase я даже не надеюсь...
И это не единственный момент, по моему... Там еще и версии копиться будет и прочее.

← →
Alexandr © (2002-12-17 14:40) [25]

нет не другая.
Забудь про retaining
и сон будет крепким, а волосы гладкими и шелковистыми...

← →
Prooksius © (2002-12-17 14:44) [26]

2 Johnmen © (17.12.02 14:36)
На этом форуме такой случай уже был. Ситуация такая же, как описал Calm.
Дело тут точно в Retaining.
Писал как-то на www.ibase.ru Дмитрию Кузменко, он не сказал ничего, ссылаясь на то, что в моем слючае Retaining использовать нет надобности.
Тут видимо, вопрос в частоте выполнения CommitRetaining. Если не часто, прокатывает, если >1 раз в сек. - грабли.
ИМХО, конечно.

>Alexandr © (17.12.02 14:40)
>Prooksius © (17.12.02 14:44)

Друзья ! Все таки ситуация разная. Если мы занимаемся исключительно инсертами, то, однозначно, COMMIT, причем через каждые несколько сотен. У автора же и SELECT и INSERT (в одной тр-ии). А здесь я не вижу разумных альтернатив COMMITRETAINING.

Ok, напугали вы меня, убираю Retainig...

Johnmen © (17.12.02 14:53)
Делал все, как ты сказал (когда заливал данные из текстового файла)
При ...Retaining тормоза и зависон, при Commit - никакого замедления (даже тенденции к замедлению) после вставки ок. 500 000 записей.
Почему?
Вроде, не должно бы...

>Prooksius © (17.12.02 14:59)

Ну что такое ...Retaining ? Просто попытка Commit с сохранением курсоров, открытых в предыдущей тр-ии.
Я вполне допускаю, что реализовано это с глюками. Но, во-первых, я с ними не сталкивался, а, во-вторых, в твоем примере только инсерты, а значит, нужен только Commit.

да все так.
Перестаньте же спорить впустую.
А то уже по второму разу одно и то же...

2 Alexandr © (17.12.02 15:21)
Вот ты Yaffil рекламируешь, а ты не пробовал такого (куча insert-ов с CommitRetaining после 100 insert-ов) на дятле?

commit retaining suxxx и я без него всегда обходился.
А вообще-то я не ракламирую, а предлагаю как лучше.

Неубедительно... Доводов не было...
И еще - интересно, как обошелся без retaining при редактируемом <...>DataSet ?

в FIBPlus с этим 0.00 проблем.
Там разные транзакции на select и редактирование.

Alexandr, попробуй заливку данных с retaining на дятле
Все-таки интересны результаты.

некогда

Не выполняется insert в ХП, вызываемой из клиентского приложения Найти похожие ветки