"Ошибка

← →
off © (2004-05-12 12:46) [0]

Привет! Такое дело: простенькая процедура типа insert... post перегоняет данные из Query в IBDataSet. И все ничего, но только на 60% вылазит сообщение:
Dynamic SQL Error SQL error code=-502 Declared cursor already exists.
При этом данные коммитятся, хотя commit стоит в самом конце. Вопрос в том почему вылезла эта кака и как от нее избавиться?

← →
Соловьев © (2004-05-12 12:50) [1]

> простенькая процедура типа insert... post

а подробнее?

← →
off © (2004-05-12 13:24) [2]

> Соловьев © (12.05.04 12:50) [1]

while not Query1.Eof do begin IBDataSet1.insert; IBDataSet1F1.AsInteger:=Query1T1.AsInteger; IBDataSet1F2.AsString:=Query1T2.AsString; IBDataSet1F3.AsInteger:=Query1T3.AsInteger; try IBDataSet1.Post; except IBDataSet1.Cancel; end; Query1.Next; end;

← →
Курдль © (2004-05-12 13:29) [3]

А как выставлены кэшированные изменения IBDataSet1?

← →
off © (2004-05-12 13:36) [4]

> Курдль © (12.05.04 13:29) [3]

CachedUpdates - False

← →
Курдль © (2004-05-12 13:37) [5]

А где тогда commit стоит в самом конце.?
И что стоит в самом начале?

← →
off © (2004-05-12 13:40) [6]

> Курдль © (12.05.04 13:37) [5]

Commit стоит после цикла while not ... do begin ... end

← →
Соловьев © (2004-05-12 13:45) [7]

> При этом данные коммитятся, хотя commit стоит в самом конце

потому как у тебя стоит AutoCommit = true

← →
Johnmen © (2004-05-12 13:48) [8]

Одно непонятно, зачем для простой вставки держать ещё и набор данных ?
Почему просто не сделать INSERT INTO ... ?

← →
Курдль © (2004-05-12 13:59) [9]

1. А какой имеет смысл Commit без режима кэшированных изменений?
2. Что прописано в IBDataSet1.InsertSQL?

← →
Johnmen © (2004-05-12 14:04) [10]

>1. А какой имеет смысл Commit без режима кэшированных изменений?

Смысл стандартный. И кеш здесь непричём. (Дежа вю...)

← →
Курдль © (2004-05-12 14:08) [11]

А разве без кэша не происходит автоматический commit после каждого post? :(

← →
Vlad © (2004-05-12 14:16) [12]

> Курдль © (12.05.04 14:08) [11]

Нет, Post и Commit никак между собой не связаны

← →
Johnmen © (2004-05-12 14:19) [13]

Я даже скажу больше
Кеш, Post и Commit никак между собой не связаны (в глобальном смысле)

← →
Курдль © (2004-05-12 14:40) [14]

Объясните мне, - бесталкешке, (ну туплю!)!
Что происходит (между клиентом и сервером), если есть TIBDatabase и связанный с ней TIBDataSet, когда скомандуешь последнему Post?

← →
Johnmen © (2004-05-12 14:54) [15]

>Что происходит (между клиентом и сервером), если есть
>TIBDatabase и связанный с ней TIBDataSet, когда скомандуешь
>последнему Post?

Если есть кеширование, то ничего.
Если нет, то выполниться соответствующий запрос.

Мои досужие мысли на тему СУБД (вдруг кому интересно).

Все СУБД создаются так, чтобы прдерживаться общепринятого протокола при работе с данными. Говоря коротко, действия с данными делятся на 2 основных вида - выборка (которая нам пока не интересна) и обновление.
Практически все изменения в данных СУБД производит по командам (инструкциям) извне. В общих чертах порядок обновления следующий:
1. От клиента поступает пакет запросов на обновление (insert/update/delete)
2. Если это первый запрос из пакета - открывается транзакция по умолчанию.
3. Выполняются все инструкции на обновление согласно запросов
4. Если приходит commit - все изменения утверждаются.
5. Если приходит rollback - все изменения отменяются.
Ключевая фраза: Если приходит commit

Мои досужие мысли о работе ДатаСэтов
I. Если не объявлены кэшированные изменения
1. При каждом post-е Датасет передает пакет из одного запроса на изменения одной записи + commit

II. При включенных кэшированных изменениях
1. При каждом изменении набора данных (insert/edit/delete) Датасет помечает затронутую запись специальным значением статуса - "добавлена/изменена/удалена", а в нетронутых оставляет статус "исходная".
2. По команде ApplyUpdates ДатаСет пробегает по всем измененным записям, выбирает для каждой соответствующий статусу запрос и передает его СУБД.
3. ДатаСет или юзер передает СУБД инструкцию Commit.
4. Если все прошло удачно, ДатаСет помечает все измененные записи, как "исходные".

Лейтмотив моей тиррады - ничто не происходит в СУБД без COMMIT-а!

> 1. При каждом post-е Датасет передает пакет из одного запроса
> на изменения одной записи + commit

Товарищ. Ну открой ты книжки умные чтоли.
Берем BDE ради классического примера.
У каждого алиаса есть параметр SQLPASSTHRU MODE, который как раз отвечает за то, нужно ли делать Commit транзакции или не нужно.
DataSet и его метод Post тут вобще непричем. Ну не отвечает он за Commit на сервере.

0. От клиента поступает команда стартовать транзакцию.
>1. От клиента поступает пакет запросов на обновление (insert/update/delete)
2. ---
...

I. Если не объявлены кэшированные изменения
1. При каждом post-е Датасет передает пакет из одного запроса на изменения одной записи. (тчк)
2. От клиента поступает команда завершить транзакцию.

II. При включенных кэшированных изменениях
1. При каждом изменении набора данных (insert/edit/delete) при вызове Post Датасет сохраняет в кеше дельту между предыдущим значением и текущим.
2. От клиента поступает команда стартовать транзакцию.
3. По команде ApplyUpdates ДатаСет формирует на основе всех дельт запросы к БД и они уходят.
4. Не прошедший запрос не сбрасывает кеш.
5. От клиента поступает команда завершить транзакцию.
6. Сами чистим кеш, если надо.

> Johnmen © (12.05.04 16:00) [18]

> I. Если не объявлены кэшированные изменения
> 1. При каждом post-е Датасет передает пакет из одного запроса
> на изменения одной записи. (тчк)
> 2. От клиента поступает команда завершить транзакцию.

Причем I.2 и II.5 совсем не обязательно. Зависит от того, какие компоненты используем и их настроек, а то может и вобще не быть сигнала ни на подтверждение ни на откат.

СУБД ничего не изменит без commit-a! Другое дело, что явно его мы не видим - компоненты сами его посылают. Вот и в примере пропавшего автора та же фигня -
> При этом данные коммитятся, хотя commit стоит в самом конце.

А с этим никто и не спорил, кажись...:)

"Ошибка - 502" Найти похожие ветки