Search Forum Home   Visual FoxPro  Baze de date, tabele, view-uri si indecsi  Audit ......  Audit ...    11/10/2011 6:34:56 PM Dragos 62 posts Audit ...  (N/A) Salut tuturor ... Am de facut la o aplicatie spre sfarsite si partea de audit. Deocamdata sistemul gestioneaza utilizatori (identificatori, sesiuni - logon logoff, parole, tipuri de utilizatori si restrictii pe forme etc.) Acum se vrea si auditare pe obiect (tabela)/ inregistrare - INSERT, UPDATE si DELETE. Ma gandesc sa fac ca pe ORACLE cu 2 tabele. Una sa-mi tina ID_USER, TIME, ACTIUNE(INSERT, UPDATE, DELETE), NUME_OBIECT (nume tabela), terminal (IP sau NUME Statie lucru). A doua tabela legata de prima va avea FOREIGN KEY din prima, si pentru fiecare FK sa aiba mai multe inregistrari. Adica pentru OBIECTUL pe care se face operatiune, sa se insereze tot atatea randuri pentru fiecare inregistrare. Fiecare rand va avea FK, Nume camp, Valoare camp. In felul acesta voi avea permanet auditata orice actiune de I,U,D pe tabela/inregistrare. Partea de actualizare pentru cele doua tabele se va face cu TRIGGERE si proceduri in DB. Baza de date are undeva peste 100 de tabele si va contine pentru vreo 30 de tabele peste 100.000 de inregistrari. Baza de date e nativa VFP. INTREBAREA Este daca VFP va face fata, iar procesele acestea in plus nu vor ingreuna lucrul in modul partajat. Ma gandesc ca pe masura ce tabelele de baza se vor incarca cu date, iar tabelele de audit vor ajunge la sute de mi de inregistrari (cel putin cea de a doua), toate procesele vor deveni mai lente. Binenteles ca vreau sa fac o chestie de descarcare atunci cand sistemul ajunge undeva la 90% grad incarcare per tabela AUDIT si sa descarc auditul in niste fisiere XML - arhive. Daca cineva a mai facut orice legat de audit pe tabele native, voi aprecia orice ajutor sau sfat.  11/11/2011 8:56:15 AM aflorin 840 posts Re: Audit ...  (N/A) Eu as avea doua observatii: a) cele doua tabele ar putea sa iti creeze ceea ce se cheama bottleneck. Adica indiferent in ce modul vei lucra, orice I/U/D pe orice tabela trebuie sa blocheze si sa scrie in tabelele de audit si sa actualizeze si eventualii indecsi. b) tabela cu Nume camp, valoare camp imi sugereaza ca vrei sa tii valorile noi (sau vechi?) pe care le inserezi/modifici/stergi. Asta inseamna cumva ca un DELETE pe 5 randuri, intr-o tabela cu 10 coloane va scrie 50 de inregistrari in aceasta tabela? E enorm. Mai adauga aici si costul conversiei in String. Florin Aparaschivei - Iasi  11/11/2011 9:17:54 AM Dragos 62 posts Re: Audit ...  (N/A) Pertinente observatiile. Si-ti multumesc ... Nu vreau sa auditez toate tabelele din DB. Probabil voi audita vreo 20 de tabele (cele mai importante - la nivel de granulatie - fiecare camp I/U/D). M-am tot gandit la asta. Pentru celelalte voi stoca doar in prima tabela tipul de actiune. Intr-adevar a doua tabela (PK/NUME CAMP/VALOARE CAMP) asta vrea sa faca. Sa tina si valorile vechi. Ceva in genul la "Fine Grained Auditing" din ORACLE. E u nu am folosit asta pentru aplicatii in ORACLE ci am facut 2 tabele cu vreau sa fac in VFP. Si acolo merg fara probleme. La punctul b) ai intuit bine. Pentr o tabela cu 10 coloane, la o adaugare a unui rand voi avea 10 inregistrari in tabela "analitica" de audit. NU VA FACE FATA VFP-ul ? Atunci orice alta solutie este binevenita. M-am gandit ca asta este cea mai rapida. Incarc in RAM la initializarea plicatiei cele 2 tabele si le actualizez. Ma gandeam si la o solutie cu fisiere pe disc, dar, s-ar putea ca timpii sa fie si mai mari. Mai ales in retea. Repet. Nu vreau sa fac AUDITARE la nivel de inregistrare/camp (I/U/D) pentru toate tabelele - doar pentru vreo 20. Pentru celelalte voi audita doar actiunea. Daca ar fi sa auditez totul la fel ar fi dezastru.  11/11/2011 9:34:50 AM Dragos 62 posts Re: Audit ...  (N/A) Ma mai gandeam sa fac AUDITAREA asta care ma sufoca si altfel. Sa nu o scriu pe triggere. Sa o fac din forme la parasirea formelor (tinand valorile actualizate I/U/D) in masive. La descarcarea formului, pe Destroy, scriu in cele 2 tabele, sau doar in una, dupa caz. Inca o data. Orice solutie este binevenita.  11/12/2011 8:54:39 AM Dragos 62 posts Re: Audit ...  (N/A) O sugestie pentru auditare operatiuni pe tabele sau documentatie ?!  11/12/2011 12:57:09 PM Grigore Dolghin 3590 posts www.class-software.eu Re: Audit ...  (N/A) #1. Sugestia mea ar fi sa o faci cu triggere, totusi, nu la inchiderea formelor, ca sa eviti eventualele pierderi de date de audit daca userul inchide aplicatia necontrolat. #2. Structura tabelelor auditate se va schimba in timp, ceea ce va implica modificari si in modulul de audit (tabele + cod). Sugestia mea ar fi ca tabelele de auditare sa aiba doar 5 campuri: PK, Original_PK, Content, Data (datetime), UserId. In Content concatenezi toate campurile din tabela auditata, transformate in string (TRANSFORM() o sa-ti fie de mare folos), separate cu un separator prestabilit. Pipe, sa zicem. ("|"). Ca sa le extragi de-acolo te folosesti GETWORDCOUT si GETWORDNUM, care permit specificarea caracterului folosit drept separator. In felul asta modificarile de structura ale tabelelor auditate nu-ti afecteaza tabelele de audit, dar va trebui sa tii cont de structura la o eventuala afisare a datelor de audit (cate coloane erau si ce contineau). Eu as face si o tabela de format, in care as tine Data, numele tabelei, lista de campuri si tipul de date. Cand se modifica structura tabelei auditate adaug o inregistrare in tabela asta de format. Cand extrag datele de audit, ma uit la tabela de format ca sa vad cate campuri erau la data aia, cum le chema si ce tip de date aveau. Restul e aritmetica. Grigore Dolghin Visual FoxPro MVP 2006 - 2010 Class Software My blog  11/12/2011 2:49:00 PM Dragos 62 posts Re: Audit ...  (N/A) Multumesc Grigore. Interesant. In cazul asta e posibil sa-mi ajunga doar o tabela pentru audit. Nu mi-ar mai trebui 2 tabele. La tabela care ai spus tu mai trebuie adaugate 2 campuri (STATIA si ACTIUNEA). Singura problema e ca e posibil ca pt. 2 tabele sa nu imi ajunga 255 de caractere deoarece au vreo 40 de coloane (daca le calculez ca marime de coloane insumate + separatorul -> trec de 255). Din cate stiu si varchar din VFP e limitat la 254. Multumesc in ca o data ...  11/12/2011 7:32:39 PM Dragos 62 posts Re: Audit ...  (N/A) Am facut o singura tabela iar "Content"-ul ala care ziceai vad ca se comporta OK - cu delimitator '|'. Cred ca o sa mearga OK. Am o intrebare simpla. Tabela de audit se deschide intr-o procedura stocat apelata de trigger. Acum am deschis-o la rece (fara buffering). Ma gandeam sa o deschid cu buffer 5. E vreo problema in modul partajat ? Stiind ca procedura asta va fi apelata non-stop de toate tabelele pentru I/U/D. Cum e mai OK ? Sa o deschid cu buffering sau fara ? Multumesc din nou ...  11/14/2011 7:49:25 AM Grigore Dolghin 3590 posts www.class-software.eu Re: Audit ...  (N/A)  Dragos wrote Multumesc Grigore. Interesant. In cazul asta e posibil sa-mi ajunga doar o tabela pentru audit. Nu mi-ar mai trebui 2 tabele. La tabela care ai spus tu mai trebuie adaugate 2 campuri (STATIA si ACTIUNEA). Singura problema e ca e posibil ca pt. 2 tabele sa nu imi ajunga 255 de caractere deoarece au vreo 40 de coloane (daca le calculez ca marime de coloane insumate + separatorul -> trec de 255). Din cate stiu si varchar din VFP e limitat la 254. Multumesc in ca o data ... One single word: Memo. Grigore Dolghin Visual FoxPro MVP 2006 - 2010 Class Software My blog  11/14/2011 7:56:55 AM Grigore Dolghin 3590 posts www.class-software.eu Re: Audit ...  (N/A)  Dragos wrote Am facut o singura tabela iar "Content"-ul ala care ziceai vad ca se comporta OK - cu delimitator '|'. Cred ca o sa mearga OK. Am o intrebare simpla. Tabela de audit se deschide intr-o procedura stocat apelata de trigger. Acum am deschis-o la rece (fara buffering). Ma gandeam sa o deschid cu buffer 5. E vreo problema in modul partajat ? Stiind ca procedura asta va fi apelata non-stop de toate tabelele pentru I/U/D. Cum e mai OK ? Sa o deschid cu buffering sau fara ? Multumesc din nou ... Nu e nici o problema, dimpotriva, chiar iti sugerez sa folosesti tranzactie + optimistic table buffering. In felul asta VFP o sa poata gestiona singur locking-ul pe tabela de audit (sunt multe comenzi VFP care pun un lock implicit, de care uneori nu stii, si daca incadrezi totul intr-o tranzactie ai control asupra intregii povesti. Deschizi tranzactia, VFP pune lock-uri cum il taie capul, faci update, ala scoate lock-urile, comiti tranzactia si gata. Ce se intampla in interiorul tranzactiei nu e treaba ta si nu-i afecteaza pe ceilalti useri fiindca oricum trebuie sa astepte pana se comite tranzactia. Grigore Dolghin Visual FoxPro MVP 2006 - 2010 Class Software My blog  11/14/2011 9:08:29 AM aflorin 840 posts Re: Audit ...  (N/A)  Dragos wrote Incarc in RAM la initializarea plicatiei cele 2 tabele si le actualizez. Asta se poate daca ai fi pe Oracle. Nu cred ca in VFP poti face asa ceva. In rest, vad ca deja ai fost indrumat. Florin Aparaschivei - Iasi  11/14/2011 5:39:05 PM Dragos 62 posts Re: Audit ...  (N/A) Uite ca am luat o decizie. Si cred ca una buna. Tranzactii sa fie. Multumesc din nou.  11/14/2011 6:11:30 PM Dragos 62 posts Re: Audit ... 1593  (Germany) Ce tampenie ... Pe butonul de salvare a formei ... SAVE-ul e pe o clasa CUSTOM care trateaza update-ul (toate tabelele pe care se fac actualizari le deschid cu buffering) - facea salvarea propriu-zisa cu TABLEUPDATE incapsulata intr-o tranzactie. Cand se produce TABLEUPDATE ==> se apeleaza procedura stocata. Pana aici e OK. Dar in procedura stocata deschid tabele de audit si vreau sa o setez buffer=5 cu CURSORSETPROP si imi crapa ... NU STIU DE CE ? Error 1593: Command cannot be issued within a transaction (Error 1593) Ma intreb ... Cat timp esti intr-o tranzactie banuiesc ca poti deschide alta, cel putin pana la level 5. Sau VFP nu permite in timpul tranzactiei sa deschid o tabela cu buffering, pana nu termin tranzactia curenta ?!  11/14/2011 6:32:19 PM Daniel Buduru 2335 posts Re: Audit ... 1593  (N/A) Schimbarea tipului de buffering (cursorsetprop("buffering", x)  nu este permisa in timpul tranzactiei. Pe de alta parte, nu ai nevoie sa setezi buffering pentru tabelele deschise in trigger, de asta se ocupa vfp in mod impicit. Orice modificare a unei tabele facuta in interiorul unei tranzactii este bufferata, astfel incat, la comanda rollback, toate modificarile facute asupra tuturor tabelelor implicate in tranzactie sa fie anulate. Daniel Buduru  11/14/2011 7:11:56 PM Dragos 62 posts Re: Audit ... 1593  (Germany) Din pacate nu stiu daca este asa. Am deschis "audist" in procedura stocata apelata de trigger. Iar dupa BEGIN TRANS ... am ncercat =TABLEUPDATE(1,.F.,"auditst") si am primit Error:1586  11/14/2011 7:25:07 PM Dragos 62 posts Re: Audit ... Trigger  (N/A) Si inca o scama ... Cum spuneam ... Am TABLEUPDATE pe tabela de date dintr-o tranzactie. La lansarea =TABLEUPDATE pe tabela de date ... se apeleaza TRIGGER-ul si procedura stocata care face INSERT in audit dupa care intr-o tranzactie face TABLEUPDATE pe tabela de audit. Ma gandeam ca daca TABLEUPDATE pe tabela de audit esueaza va face ROLLBACK si pe tabela de date, ceea ce e NASOL. Daca datele se salveaza OK ... si din anumite considerente nu se salveaza acea inregistrare in audit (o pierd efectiv) ASTA E. Mda ... Nu ma gandeam ca o sa-mi dea atatea batai de cap.  11/14/2011 7:45:47 PM Daniel Buduru 2335 posts Re: Audit ... Trigger  (N/A)  Dragos wrote Si inca o scama ... Cum spuneam ... Am TABLEUPDATE pe tabela de date dintr-o tranzactie. La lansarea =TABLEUPDATE pe tabela de date ... se apeleaza TRIGGER-ul si procedura stocata care face INSERT in audit dupa care intr-o tranzactie face TABLEUPDATE pe tabela de audit. Ma gandeam ca daca TABLEUPDATE pe tabela de audit esueaza va face ROLLBACK si pe tabela de date, ceea ce e NASOL. Daca datele se salveaza OK ... si din anumite considerente nu se salveaza acea inregistrare in audit (o pierd efectiv) ASTA E. Mda ... Nu ma gandeam ca o sa-mi dea atatea batai de cap. Daca ASTA E cu inregistrarea de audit, ma intreb cum se va transa problema in cazul in care se constata ca o inregistrare nu exista in audit? Se va considera cumva o tentativa de frauda din partea unui user/admin? Ce rost mai are auditarea, daca pleci de la premisa ca este posibil ca unele tranzactii sa nu fie inregistrate in audit? Rostul unei tranzactii pe o baza de date este tocmai asta: ori se salveaza toate inregistrarile in toate tabelele, ori nu se salveaza nimic. Daca salvarea in tabela de audit esueaza, iar in celelalte tabele nu, problema este  doar in codul tau si trebuie sa il corectezi, nu sa treci peste asta. Daniel Buduru  11/14/2011 7:53:34 PM Daniel Buduru 2335 posts Re: Audit ... 1593  (N/A)  Dragos wrote Din pacate nu stiu daca este asa. Am deschis "audist" in procedura stocata apelata de trigger. Iar dupa BEGIN TRANS ... am ncercat =TABLEUPDATE(1,.F.,"auditst") si am primit Error:1586 Spuneam ca in tranzactii VFP buffereaza implicit, nu explicit. In tabela deschisa in tranzactie scrii direct, ca si cand ar avea buffering=0. Ce scrii tu VFP pune intr-un buffer, iar tabela se actualizeaza la end tranzaction, sau bufferul se goleste la rollback, nu ai nevoie de tableupdate sau tablerevert pe aceasta tabela. Fa un test si te vei convinge. Nici macar nu trebuie sa scrii cod in trigger pentru asta. In command scrie begin transaction, apoi use tabela, adauga 2-3 inregistrari, apoi da comanda Rollback. Daca vrei sa lucrezi cu tabela bufferata, trebuie sa o deschizi in afara tranzactiei, dar asta nu are sens in acest caz.. Daniel Buduru  11/14/2011 8:13:35 PM mmarius28 139 posts Re: Audit ... Trigger  (N/A)  Daniel Buduru wrote Ce rost mai are auditarea, daca pleci de la premisa ca este posibil ca unele tranzactii sa nu fie inregistrate in audit? Rostul unei tranzactii pe o baza de date este tocmai asta: ori se salveaza toate inregistrarile in toate tabelele, ori nu se salveaza nimic. Daca salvarea in tabela de audit esueaza, iar in celelalte tabele nu, problema este  doar in codul tau si trebuie sa il corectezi, nu sa treci peste asta. Asa este. In schimb, cred ca este o logica sa salvezi intr-o tabela log/audit actiunile unei proceduri mai lungi care, daca da eroare si face rollback automat, da rollback si la inregistrarile adaugate in tabela log/audit. In cazul acesta, ar trebui ca scrierea in log sa se faca in cadrul unei tranzactii autonome (in Oracle este posibil), astfel incat commit-ul in log/audit sa nu afecteze tranzactia principala si invers.  11/14/2011 8:35:12 PM Daniel Buduru 2335 posts Re: Audit ... Trigger  (N/A)  mmarius28 wrote  Daniel Buduru wrote Ce rost mai are auditarea, daca pleci de la premisa ca este posibil ca unele tranzactii sa nu fie inregistrate in audit? Rostul unei tranzactii pe o baza de date este tocmai asta: ori se salveaza toate inregistrarile in toate tabelele, ori nu se salveaza nimic. Daca salvarea in tabela de audit esueaza, iar in celelalte tabele nu, problema este  doar in codul tau si trebuie sa il corectezi, nu sa treci peste asta. Asa este. In schimb, cred ca este o logica sa salvezi intr-o tabela log/audit actiunile unei proceduri mai lungi care, daca da eroare si face rollback automat, da rollback si la inregistrarile adaugate in tabela log/audit. In cazul acesta, ar trebui ca scrierea in log sa se faca in cadrul unei tranzactii autonome (in Oracle este posibil), astfel incat commit-ul in log/audit sa nu afecteze tranzactia principala si invers. Daca se auditeaza aplicatia, e util ca logul sa nu fie afectat de tranzactie. Dar daca se auditeaza tranzactiie bazei de date, nu are sens pastrarea in  tabela de audit a unor inregistrari necomise. Cand tranzactia esueaza, inregistrarile raman in buffer, in cazul in care se lucreaza cu buffering>0, deci nu e necesara reintroducerea datelor, ci numai revizuirea acelor date care au provocat rejectarea inregistrarii, apoi se executa din nou secventa de salvare. Vfp nu permite tranzactii autonome in aceeasi sesiune de date (datasession), ci numai tranzactii imbricate. Daniel Buduru  11/14/2011 9:52:38 PM Dragos 62 posts Re: Audit ... 1593  (N/A) Va multumesc tuturor ... Prima chestie legat de acestea in sfarsit a inteles-o cineva. Si ii multumesc pe aceasta cale. Vroiam ca ceea ce facea trigger-ul pe partea de audit sa fie independent de restul. Dar cum spuneam, probabil ca pe VFP nu se poate. Sau e chiar sigur. In ceea ce priveste, tranzactiile problema se pune astfel. Daca nu deschid tabela auditata cu buffering, fac BEGIN TRAN ... inserez randuri, si apoi END TRAN ... cu ce testez daca tranzactia generata de trigger s-a comis sau nu ?! TABLEUPDATE imi spunea asta. Si daca nu s-a comis, face VFP-ul ROLLBACK automat ? Daca tranzactia nu s-a comis in DB (pe tabela de audit) imi va face rollback si pe tabela de date, dar fara sa stiu sursa problemei (de fapt user-ul, nu eu). Naspa. Mult mai bine cu server-e de DB. Si, intr-adevar. Sunt de acord ca orice inregistrare, inserata, stersa, actualizata trebuie auditata. Daca se vrea auditare. Repet. As fi vrut ca procesele sa fie separate si nu in acelasi bloc. Inca o data va multumesc.  11/14/2011 10:14:49 PM Daniel Buduru 2335 posts Re: Audit ... 1593  (N/A) Se poate si in vfp ca ceea ce face trigger-ul pe partea de audit sa fie independent de restul. Trebuie doar sa te hotarasti ce anume vrei sa auditezi si cum. Ar trebui sa studiezi un pic tranzactille bazei de date inainte de a scrie cod si de a trage concluzii, pentru ca cele pe care le tragi sunt eronate. Comenzile Rollback si End transaction le dai tu in cod, nu le da vfp intern. Vfp nu face nici una, nici alta. Daca datele din inregistrare violeaza field rule, record rule, primary key, candidate key, referential integrity, vfp ridica eroarea corespunzatoare. Error handler-ul tau trebuie sa intercepteze eroarea, iar codul tau da comabda end transaction sau rollback, in functie de ce intoarce eroor handler-ul. Nu se intampla nimic ascuns, decat daca nu stii cum functioneaza.. Uite cateva articole, din care vei putea intelege cum functioneaza tranzactiile: http://fox.wikis.com/wc.dll?Wiki~TransactionsAndBuffering http://www.jamesbooth.com/transactions.htm http://msdn.microsoft.com/en-us/library/ms947432.aspx http://www.foxite.com/articles/read.aspx?id=75&document=moving-from-single-user-to-multiuser-in-vfp Ai dreptate in privinta serverelor, e mult mai bine cu ele. Dar si acolo vei avea de rezolvat aceleasi probleme in privinta tranzactiilor, chiar daca sunt mai granulare decat in vfp. Stii cum se spune, copii mici, probleme mici, copii mari, probleme mari ... Daniel Buduru  11/15/2011 10:55:41 AM Dragos 62 posts Re: Audit ... 1593  (N/A) Daniel, n-am spus nici o clipa ca VFP face automat BEGIN TRANSACTION sau ROLLBACK. S-ar putea ca ceea ce am incercat eu sa spun sa fi fost inteles eronat. Si poate ca nu am fost destul de explicit. Imi cer scuze daca a fost asa. Iar ce face VFP implicit (blocari, deblocari) le stiu si pe astea. Tu ai dreptate in multe privinte. Iar aplicatia e construita incat are o rutina globala (catchError) pentru tratarea erorilor din DB cat si din forme. Inca o data repet. As fi vrut ca tranzactia pentru audit sa fie independenta-autonoma de tranzactia pentru datele efective. Ma gandeam ca as putea incerca sa fac un "wrapper" separat de aplicatie, in cazul in care DB este pe un server de Windows, care va functiona non-stop si va capta ce se intampla pe tabele. In acest fel pertea de auditare ar fi independenta de aplicatia propriu-zisa. Asta apropo de faptul daca trebuie introdusa in auditare si o inregistrare care nu a fost salvata (scrisa pe disc). D.p.m. de vedere, daca e audit, trebuie sa auditeze totul. Chestia asta este totusi un pic mai complexa si necesita timp. Voi ramane cred la modul de abordare despre care am vorbit. Discutia aceasta a fost benefica si sper sa-i ajute si pe altii. Si sper ca nu am suparat pe nimeni. Pana la urma este un forum. Nimeni nu cred ca le-a facut pe toate sau s-a lovit de toate. Va multumesc tuturor. Si va voi tine la curent, daca intereseaza pe cineva, cum va evolua aceasta chestie care se cheama AUDIT pe baze de date native VFP.  11/15/2011 11:42:13 AM Daniel Buduru 2335 posts Re: Audit ... 1593  (N/A) Daca am lasat impresia ca sunt suparat pe tine, imi pare rau. Asa este, e un forum, in care fiecare isi poate expune parerea, si fiecare raspunde daca doreste sa o faca. Totusi, pentru cei care citesc acest forum, fara a participa la discutii, e bine ca informatiile pe care le capata de aici, in special privind functionarea vfp, sa fie corecte. De aici si interventia mea. Daca vrei sa excluzi actualizarea unor tabela din tranzactie, ai doua cai: - tabelele sa fie free-tables, adica s anu faca parte dintr-o baza de date, intrucat tranzactia functioneaza doar pe tabela incluse in dbc. Cu o observatie, totusi: in VFP9 SP2 exista functiile  MAKETRANSACTABLE, care permite efectuarea tranzactiilor si pe free-table si cursor, si ISTRANSACTABLE, care reurneaza starea tabelei (tranzactionabila sau nu) - deschiderea tabelelor care se doresc a fi excluse din tranzactie intr-o alta datasession, comenzile BEGIN TRANSACTION, END TRANSACTION si ROLLBACK fiind specifice sesiiunii de date. Revenind la Audit, atata vreme cat se auditeaza modificarea bazei de date, nu are sens ca tabela audit sa fie exclusa din tranzactia care actualizeaza baza de date. Asta este o regula, nu o optiune. In Audit trebuie sa se gaseasca istoricul operatiilor efectuate, nu se admite ca din el sa lipseasca operatii si nici sa contina operatii care nu s-au comis. Daca vrei sa tii si operatiile necomise, va trebui sa intrduci o informatie suplimentara legata de comiterea operatiei, iar gestionarea acestei informatii e mult mai complicata decat pare. Daca vrei sa auditezi aplicatia, poti tine un log al operatiilor efectuate si starea lor succes/esec, dar nu in acceasi tabela cu auditul bazei de date. Daniel Buduru  11/15/2011 11:52:32 AM Dragos 62 posts Re: Audit ... 1593  (N/A) Multumesc Daniel. Discutia a fost benefica. Si m-a facut sa rezolv si niste chestii nerezolate. In ceea ce priveste auditul, ai dreptate. Va tin la curent.  Page 1 of 1   Visual FoxPro  Baze de date, tabele, view-uri si indecsi  Audit ...... Flat View Tree View Oldest To Newest Newest To Oldest