Чому дані можуть не зберігатися?
Трехзвенное додаток (TClientDataSet, TDCOMConnection, TPatasetProvider, TDataBase, TQuery). На клієнті оформляється прихід товару. Дані забиваються в TClientDataSet. Потім натискають кнопку "Провести", в результаті чого виконується приблизно наступний код:
На клієнті:
AppServer.StartTransaction; // Фактично DataBase.StartTransaction
Prihod.ApplyUpdates (0); // Зберігаємо зміни в БД
AppServer.CreatePrihodDoc (.);
На віддаленому сервері функція виглядати приблизно так:
procedure CTradeServer.CreatePrihodDoc (.);
begin
# XA0; Goods.Open; // CommitUpdates = True. Лежить в TRemoteDataModule
# XA0; Партіі.Open; // Таблиця партій, властивості теже
# XA0; try
# XA0; # XA0; # XA0; # XA0; приходу в таблиці партій товарів (і ще в 4-х таблицях)>
# XA0; # XA0; Goods.ApplyUpdates; // Збереження змін в БД
# XA0; finally
# XA0; # XA0; Goods.Close;
# XA0; # XA0; Партіі.Close;
# XA0; end;
end;
Виклик Prihod.ApplyUpdates (0) зберігає внесені зміни в табличку Goods.db на сервері. Далі в функції CreatePrihodDoc відкривається кешированний набір даних Goods, відповідної тієї ж самої Goods.db і при успішному внесення змін виконується ApplyUpdates, завдяки чому внесені в даній функції зміни записуються в Goods.db.
Код на кшталт корректрий. Скільки разів він уже тестувався на роботі - не разу не давав збоїв. а от клієнти часом скаржаться. Роблять прихід по одному документу кількох десятків товарів - операція спрацьовує без помилок. Однак проведені найменування товарів в базі не зберігаються. Найгірше в тому, що в функції CreatePrihodDoc () виконується запис необхідної інформації про прихід і в інші таблички. Так у всіх табличках інформація зберігається, а ось в Goods.db - ніфіга. Причину не можу знайти. Клієнт може виконати сотню парафій нормально, а потім може зловити дану помилки (після неї зазвичай доводиться видаляти "зайву" інформацію з БД, що в деяких випадках зовсім непросто).
Можливо хтось стикався з такою поведінкою BDE. Ну фік його знає, що можна придумати, і як таке налагоджувати :( Можливо, після Goods.ApplyUpdates варто додати Goods.CommitUpdates, але щось сумніваюся, що це допоможе вирішити проблему. Знаю, що BDE - ацтой, але іншого поки непередбачених , і якось потрібно викручуватися.
Один раз з цієї ж помилкою був узагалі дивак випадок:
Товарознавець зробив прихід товару. Далі майже дві доби з цим товаром велася продаж. Після чого виявилося, що цього товару в Goods.db немає, і взагалі не було. Фантастичний випадок, але на жаль - реальний: ((
# XA0; # XA0; # XA0; приходу в таблиці партій товарів (і ще в 4-х таблицях)>
# XA0; Goods.ApplyUpdates; // Збереження змін в БД
finally
напевно виключення проскакували.
Так лог помилок і ведеться. І з нього видно, що ніяких винятків тут не відбувалося.
Так paradox чи ні?
> Приходу в таблиці партій товарів (і ще в 4-х таблицях)>
а волшкбние 255 змін в рамках однієї транзакції не може превисмть оформлення в п'яти таблицях?
> А волшкбние 255 змін в рамках однієї транзакції не може
> Превисмть оформлення в п'яти таблицях?
Там обмеження в 255 змін для кожної таблиці.
В цьому випадку виникає виняток "Too many records lock on table".
Ця ситуація контролюється на стороні клієнта. Хоча, в разі, якщо вона все ж виникає - нічого страшного, так як відкат транзакції скасує виконані зміни. Але в даному випадку ця ситуація не виникає. В одному приході зазвичай більше 20 товарів не оформляють. Так що помилка не в цьому.
Нарешті причина помилки незбереження даних знайдена. Знадобився рік роботи з BDE + Paradox, щоб виявити наступну неприємну особливість: якщо з однією таблицею БД встановлено кілька з'єднань (TTable або TQuery з RequestLive = True), то ФАКТИЧНА запис змін в таблицю * .db виконається ТІЛЬКИ після того, як будуть закриті ВСІ з'єднання (причому це не залежить від ApplyUpdates). І не дай бог хоч одна програма, нехай навіть вона просто використовує TTable для відображення записів, буде закрита "нелегально", всі зміни, внесені БУДЬ-ЯКИМ кількістю програм в таблицю БД будуть втрачені, а це може бути і день і два і тиждень роботи.
Оооочень неприємна особливість, скажу я Вам. (
Багато різного було за 8 років роботи з парадоксом. Ще починаючи з повертурбо. Але такого.
Чудесні діла твої господні, а може варто налаштувати БДЕ?
Можливо. Найголовніше - розібрався з причиною помилки. Залишилося прийняти заходи до її подальшого "недопущення".
Можна але не потрібно, є ж настройки, які відповідають за це і вони працюють в не залежності викликав ти DbiSaveChanges чи ні.
Пам'ять: 0.75 MB
Час: 0.047 c