De ce nu pot fi salvate datele?
Aplicație pe trei niveluri (TClientDataSet, TDCOMConnection, TPatasetProvider, TDataBase, TQuery). Clientul face sosirea bunurilor. Datele sunt introduse în TClientDataSet. Apoi faceți clic pe butonul "Conduct", drept urmare, se execută următorul cod:
Pe client:
AppServer.StartTransaction; // De fapt, DataBase.StartTransaction
Prihod.ApplyUpdates (0); // Salvați modificările la baza de date
AppServer.CreatePrihodDoc (.);
Pe un server de la distanță, funcția arată astfel:
procedura CTradeServer.CreatePrihodDoc (.);
începe
# xA0; Goods.Open; // CommitUpdates = Adevărat. Se află în TRemoteDataModule
# xA0; Parts.Open; // Tabele de partide, proprietăți
# xA0; încercați
# xA0; # xA0; # xA0; # xA0; sosirea în tabel a loturilor de bunuri (și în alte 4 tabele)>
# xA0; # xA0; Goods.ApplyUpdates; // Salvați modificările la baza de date
# xA0; în cele din urmă
# xA0; # xA0; Goods.Close;
# xA0; # xA0; Parts.Close;
# xA0; sfârșitul;
se încheie;
Apelul la Prihod.ApplyUpdates (0) salvează modificările aduse etichetei Goods.db pe server. Mai târziu, în CreatePrihodDoc funcție deschide setul de date din memoria cache Produse corespunzătoare aceleiași Goods.db și de modificare cu succes a ApplyUpdates efectuate, a făcut astfel la această funcție modificări sunt înregistrate în Goods.db.
Codul pare să fie corect. De câte ori a fost deja testat la locul de muncă - nu a eșuat niciodată. dar clienții se plâng uneori. Sosirea unui document de mai multe zeci de bunuri - operația este declanșată fără erori. Cu toate acestea, numele bunurilor din baza de date nu sunt salvate. Cel mai rău lucru este că funcția CreatePrihodDoc () scrie informațiile necesare despre sosire în alte tabele. Deci, în toate tabletele informațiile sunt salvate, dar în Goods.db - nifiga. Motivul pe care nu îl pot găsi. Clientul poate executa în mod obișnuit o sută de parohii, iar apoi poate detecta această eroare (după ce este de obicei necesar să ștergeți informațiile "extra" din baza de date, care în unele cazuri nu este ușor).
Poate că cineva a întâmpinat un astfel de comportament al BDE. Ei bine, fic-l cunosc, vă puteți gândi, și modul în care o astfel de depanare :( Poate că după Goods.ApplyUpdates în valoare de adăugarea Goods.CommitUpdates, dar mă îndoiesc că va ajuta la rezolvarea unei probleme știu că BDE -. Atstoy, dar încă un alt neprevăzut , și cumva trebuie să ieșiți.
O dată cu aceeași eroare a fost, în general, un caz minunat:
Commodore a făcut sosirea bunurilor. Apoi, aproape două zile cu acest produs a fost vândut. Apoi, sa dovedit că nu există astfel de bunuri în Goods.db și că nu a existat deloc. Un caz fantastic, dar din păcate - real: ((
# xA0; # xA0; # xA0; sosirea în tabel a loturilor de bunuri (și în alte 4 tabele)>
# xA0; Goods.ApplyUpdates; // Salvați modificările la baza de date
în cele din urmă
pentru anumite excepții sărit peste.
Deci, jurnalul de erori este păstrat. Și arată că nu există excepții.
Deci, paradoxal sau nu?
> sosirea în tabel a unor loturi de mărfuri (și în alte 4 tabele)>
și volhkbnye 255 modificări într-o singură tranzacție nu poate depăși designul în cinci tabele?
> și volhkbnye 255 modificări în cadrul unei singure tranzacții nu pot
> Depășiți designul în cinci tabele?
Există 255 constrângeri pentru fiecare tabel.
În acest caz, apare excepția "Prea multe înregistrări blocare pe masă".
Această situație este controlată de partea clientului. Deși, în cazul în care apare chiar, este în regulă, deoarece revocarea tranzacției va suprascrie modificările efectuate. Dar în acest caz nu apare această situație. Într-o parohie, de regulă, mai mult de 20 de mărfuri nu sunt emise. Deci, greșeala nu este asta.
În cele din urmă, sa descoperit cauza erorii de protecție non-date. A fost nevoie de un an de lucru cu BDE + Paradox, pentru a detecta urme de caracteristică neplăcută: în cazul în care o singură bază de date tabel are mai multe conexiuni (TTable sau TQuery cu RequestLive = true), atunci înregistrarea efectivă a modificărilor din tabel * .db efectuat o singură dată va fi închis toate conexiune (și nu depinde de ApplyUpdates). Și Doamne ferește, cel puțin un program, chiar dacă se folosește doar TTable pentru a afișa înregistrări, va fi închis „ilegale“, toate modificările efectuate la orice număr de programe din tabelul bazei de date vor fi pierdute și poate fi zi și două săptămâni de muncă.
Oooochen caracteristică neplăcută, vă spun. (
Au fost multe lucruri diferite în opt ani de lucru cu paradoxul. Încă începe cu poverurbo. Dar asta.
Minunate sunt faptele tale și poate ar trebui să înființezi BDE?
Poate. Cel mai important - a constatat cauza erorii. Rămâne să se ia măsuri pentru ao preveni în continuare.
Este posibil, dar nu este necesar, există aceleași setări care sunt responsabile pentru acest lucru și lucrează în a determina dacă ați cauzat DbiSaveChanges sau nu.
Memorie: 0,75 MB
Lungime: 0.047 sec
Articole similare
Trimiteți-le prietenilor: