Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Loginov Dmitry © (2007-05-31 15:59:00)
Трехзвенное приложение (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 - ацтой, но другого пока непредвидится, и как-то нужно выкручиваться...

Германн (2007-06-20 01:26:00) [1]

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

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

Anatoly Podgoretsky (2007-06-20 01:09:00) [2]
> Германн (20.06.2007 00:57:10) [10]

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

Германн (2007-06-20 00:57:00) [3]

> Loginov Dmitry © (20.06.07 00:51) [9]

Лично мне помогала DbiSaveChanges при работе с парадоксом.

Loginov Dmitry (2007-06-20 00:51:00) [4]
Возможно. Самое главное - разобрался с причиной ошибки. Осталось принять меры к ее дальнейшему "недопущению".

Anatoly Podgoretsky (2007-06-20 00:26:00) [5]
> Loginov Dmitry (19.06.2007 23:53:06) [6]

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

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

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

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

Loginov Dmitry (2007-06-01 09:54:00) [8]
> а волшкбные 255 изменений в рамках одной транзакции не может
> превысмть оформление в пяти таблицах?

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

ЮЮ (2007-06-01 09:35:00) [9]
Так paradox или нет?

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

Loginov Dmitry (2007-06-01 09:23:00) [10]
Так лог ошибок и ведется. И из него видно, что никаких исключений тут не происходило.

turbouser (2007-06-01 02:47:00) [11]

> Loginov Dmitry ©

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

Loginov Dmitry (2007-05-31 16:06:00) [12]
Один раз с этой же ошибкой был вообще чудной случай:
Товаровед сделал приход товара. Далее почти двое суток с этим товаром велась продажа. После чего оказалось, что этого товара в Goods.db нет, и вообще не было. Фантастический случай, но к сожалению - реальный :((

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »