Почему данные могут не сохраняться?

← →
Loginov Dmitry © (2007-05-31 15:59) [0]

Трехзвенное приложение (TClientDataSet, TDCOMConnection, TPatasetProvider, TDataBase, TQuery). На клиенте оформляется приход товара. Данные вбиваются в TClientDataSet. Затем нажимают кнопку "Провести", в результате чего выполняется примерно следующий код:

На клиенте:
AppServer.StartTransaction; // Фактически DataBase.StartTransaction Prihod.ApplyUpdates(0); // Сохраняем изменения в БД AppServer.CreatePrihodDoc(...); AppServer.CommitTransaction; // DataBase.Commit

На удаленном сервере функция выглядет примерно так:

procedure CTradeServer.CreatePrihodDoc(...); begin Goods.Open; // CommitUpdates=True. Лежит в TRemoteDataModule Партии.Open; // Таблица партий, свойства теже try {Оформление документа прихода. Регистрация прихода в таблице партий товаров (и еще в 4-х таблицах)} Goods.ApplyUpdates; // Сохранение изменений в БД finally Goods.Close; Партии.Close; end; end;

Вызов Prihod.ApplyUpdates(0) сохраняет внесенные изменения в табличку Goods.db на сервере. Далее в функции CreatePrihodDoc открывается кэшированный набор данных Goods, соответствующей той же самой Goods.db и при успешном внесении изменений выполняется ApplyUpdates, благодаря чему внесенные в данной функции изменения записываются в Goods.db.

Код вроде корректрый. Сколько раз он уже тестировался на работе - не разу не давал сбоев. а вот клиенты порой жалуются. Делают приход по одному документу нескольких десятков товаров - операция срабатывает без ошибок. Однако проведенные наименования товаров в базе не сохраняются. Самое плохое в том, что в функции CreatePrihodDoc() выполняется запись необходимой информации о приходе и в другие таблички. Так во всех табличках информация сохраняется, а вот в Goods.db - нифига. Причину не могу найти. Клиент может выполнить сотню приходов нормально, а потом может словить данную ошибки (после нее обычно приходится удалять "лишнюю" информацию из БД, что в некоторых случаях совсем непросто).

Возможно кто-нибудь сталкивался с таким поведением BDE. Ну фик его знает, что можно придумать, и как такое отлаживать :( Возможно, после Goods.ApplyUpdates стоит добавить Goods.CommitUpdates, но что-то сомневаюсь, что это поможет решить проблему. Знаю, что BDE - ацтой, но другого пока непредвидится, и как-то нужно выкручиваться...

← →
Loginov Dmitry © (2007-05-31 16:06) [1]

Один раз с этой же ошибкой был вообще чудной случай:
Товаровед сделал приход товара. Далее почти двое суток с этим товаром велась продажа. После чего оказалось, что этого товара в Goods.db нет, и вообще не было. Фантастический случай, но к сожалению - реальный :((

← →
turbouser © (2007-06-01 02:47) [2]

> Loginov Dmitry ©

Paradox? Тогда ничего удивительного. С этим зверем все может быть :)
Лог ошибок должен вестись, между прочим. В этом блоке
try {Оформление документа прихода. Регистрация прихода в таблице партий товаров (и еще в 4-х таблицах)} Goods.ApplyUpdates; // Сохранение изменений в БД finally
наверняка исключения проскакивали.

← →
Loginov Dmitry © (2007-06-01 09:23) [3]

Так лог ошибок и ведется. И из него видно, что никаких исключений тут не происходило.

← →
ЮЮ © (2007-06-01 09:35) [4]

Так paradox или нет?

> прихода в таблице партий товаров (и еще в 4-х таблицах)}
а волшкбные 255 изменений в рамках одной транзакции не может превысмть оформление в пяти таблицах?

← →
Loginov Dmitry © (2007-06-01 09:54) [5]

> а волшкбные 255 изменений в рамках одной транзакции не может
> превысмть оформление в пяти таблицах?

Там ограничения в 255 изменений для каждой таблицы.
В этом случае возникает исключение "Too many records lock on table".
Эта ситуация контроллируется на стороне клиента. Хотя, в случае, если она всеже возникает - ничего страшного, так как откат транзакции отменит выполненные изменения. Но в данном случае эта ситуация не возникает. В одном приходе обычно более 20 товаров не оформляют. Так что ошибка не в этом.

← →
Loginov Dmitry © (2007-06-19 23:53) [6]

Наконец-то причина ошибки несохранения данных найдена. Понадобился год работы с BDE + Paradox, чтобы обнаружить следующую неприятную особенность: если с одной таблицей БД установлено несколько соединений (TTable или TQuery с RequestLive=True), то ФАКТИЧЕСКАЯ запись изменений в таблицу *.db выполнится ТОЛЬКО после того, как будут закрыты ВСЕ соединения (причем это не зависит от ApplyUpdates). И не дай бог хоть одна программа, пусть даже она просто использует TTable для отображения записей, будет закрыта "нелегально", все изменения, внесенные ЛЮБЫМ количеством программ в таблицу БД будут потеряны, а это может быть и день и два и неделя работы.
Оооочень неприятная особенность, скажу я Вам... :(

← →
Mike Kouzmine © (2007-06-20 00:03) [7]

Loginov Dmitry © (19.06.07 23:53) [6] Понадобился год работы с BDE + Paradox, чтобы обнаружить следующую неприятную особенность: ....

Много разного было за 8 лет работы с парадоксом. Еще начиная с повертурбо.... Но такого ............

← →
Anatoly Podgoretsky © (2007-06-20 00:26) [8]

> Loginov Dmitry (19.06.2007 23:53:06) [6]

Чудесны дела твои господни, а может стоит настроить БДЕ?

Возможно. Самое главное - разобрался с причиной ошибки. Осталось принять меры к ее дальнейшему "недопущению".

> Германн (20.06.2007 00:57:10) [10]

Можно но не нужно, есть же настройки, которые отвечают за это и они работают в не зависимости вызвал ли ты DbiSaveChanges или нет.

> Anatoly Podgoretsky © (20.06.07 01:09) [11]
>
> > Германн (20.06.2007 00:57:10) [10]
>
> Можно но не нужно, есть же настройки, которые отвечают за
> это и они работают в не зависимости вызвал ли ты DbiSaveChanges
> или нет.
>

Я при работе с Парадоксом больше привык полагаться на "шаманские пляски с бубном" :) Например в некоем моём клиенте, который только читает базу, в Application.OnException "глушатся" намертво исключения DBIERR_INDEXOUTOFDATE.

Почему данные могут не сохраняться? Найти похожие ветки