Search Forum Home   Visual FoxPro  Cod, sintaxa si comenzi  Updatare tabele...  Updatare tabele ale unei baze de date dintr-o aplicatie    5/13/2010 10:43:50 AM Ovidiu Dobie 105 posts Updatare tabele ale unei baze de date dintr-o aplicatie  (N/A) Am o mica aplicatie scrisa in VFP 9 la care tot adaug noi update-uri. Cand modific structura tabelelor cu MODIFY STRUCTURE (adica visual prin Project Manager) trebuie sa fac o posibilitate de update a bazei de date, mai exact a tabelelor *.dbf modificate. Am incercat sa fac o procedura pe care sa-l rulez la client, deoarece clientul are date deja introduse in tabela si ceea ce am facut eu acasa prin Project Manager vreau sa fac la el, care nu are VFP 9 instalat, automat, prin aceea procedura. Am folosit ALTER TABLE, dar nu mi-a mers... Testele le-am facut acasa, ruland "procedura" de update.. dar nu a facut modificarile. Sincer, aceste teste le-am facut cu multa vreme in urma ... numai cred ca as gasi "procedura" aceea sa o postez aici. Atunci, mai demult, am rezolvat problema, cerand baza de date a clientului, nelasandu-l sa lucreze in aplicatie 2-3 ore, i-am modificat acasa baza lui de date si i-am dus-o din nou ... a fost ok, desi stiam ca nu e profi asa. Cand a aparut al doilea client, deja "metoda mea super originala" a fost si mai depasita... Imi puteti da niste sfaturi. E ok sa mai incerc sa fac cu ALTER TABLE ... ? E metoda cea mai buna? Si inca o intrebare: Nu stiu exact daca am dreptate, dar daca lucrez cu tabele *.dbf asociate unei baze de date, nu free tables, totusi pot sa lucrez cu acele tabele (sa fac, de exemplu, APPEND BLANK in tabela) fara sa fac OPEN DATABASE ? Ati observat ca eu sunt in pe stil vechi, cu APPEND si nu INSERT INTO ... deoarece nu stapanesc prea bine limbajul SQL. Eu scriu interogari SQL ci mi-e mult mai simplu sa fac Views din VFP ... Stiu ca ar trebui sa invat sa stapanesc SQL, dar se pare ca inca nu m-am apucat Ovidiu Dobie  5/13/2010 11:24:14 AM Daniel Buduru 2335 posts Re: Updatare tabele ale unei baze de date dintr-o aplicatie  (N/A) Modificarea structurii unei tabele cu MODIFY STRUCTURE lucreaza tot cu comenzi ALTER TABLE .... Daca ceva nu a functionat, undeva a fost o eroare ... In ceea ce priveste modificarea structurii bazei de date la client, eu am adoptat intotdeauna varianta cu crearea unei noi baze de date si importul din vechea baza de date. E o metoda sigura, care, pe langa backup-ul automat pe care il face, permite si o procesare a datelor in timpul importului, cum ar fi concatenarea sau scindarea unor campuri, inlocuirea unui camp cu o referinta la alta tabela, si altele. Se scrie un program pentru aceasta operatie, avand grija ca ordinea in care se face importul in tabele sa nu genereze erori de integritate referentiala - ex. tabela clienti trebuie importata inaintea tabelei facturi, daca intre cele doua exista o relatie pe idclient, cu o clauza on insert restrict; daca in tabela clienti este referita o tabela judete, aceasta trebuie importata inaintea tabelei clienti. Baza de date din care face parte o tabela se deschide automat odata cu tabela, daca nu a fost deschisa mai inainte. Deschiderea explicita a bazei de date inainte de a deschide tabelele prezinta avantajul ca nu mai este necesara precizarea caii tabelei pe care vrem sa o deschidem. Se poate lucra cu tabelele incluse intr-o baza de date la fel ca si cu tabelele free, nu este aproape nici o diferenta. APPEND, INSERT, REPLACE, SCAN sunt comenzi dbaseII, si dateaza din anii 70, cand IBM a considerat ca 640KB RAM vor ajunge sa ti-i pui si-n cap, iar capacitatea maxima adresabila pe un disc era de 32MB. Fox a pastrat compatibilitatea in jos aproape la 100%, sunt doar cateva comenzi care nu mai functioneaza, cum ar fi PEEK si POKE, LOAD BINARY ... Se pot rula programe dbaseII in VFP9, dar nu este un motiv pentru a lucra in continuare asa. Utilizand SQL si buffering programarea devine mult mai simpla si fiabila decat folosind comenzile dbase. Iar combinatia VFP + un server SQL e varianta de preferat pentru o aplicatie multiuser. Daniel Buduru  5/20/2010 12:19:46 PM Ovidiu Dobie 105 posts Re: Updatare tabele ale unei baze de date dintr-o aplicatie  (N/A) ...Inca mai rumeg gandindu-ma la postul scris de tine... Am observat ca eu am scris in ultimele randuri asta: Eu scriu interogari SQL ci mi-e mult mai simplu sa fac Views din VFP ... Stiu ca ar trebui sa invat sa stapanesc SQL, dar se pare ca inca nu m-am apucat de fapt am uitat un NU, care poate s-a subinteles: Eu NU scriu interogari SQL ci mi-e mult mai simplu sa fac Views din VFP ... Stiu ca ar trebui sa invat sa stapanesc SQL, dar se pare ca inca nu m-am apucat Iar, despre postul tau, totul e ok si clar... Poate doar faptul ca daca eu vreau sa modific doar un camp NumeCamp care era C(3) in C(5) atunci nu prea vad rostul sa salvez si sa import intreaga baza de date din cea veche in cea noua ... DAR ultimele 2 propozitii mi-au dat mult de gandit... Mai ales ca in ultima perioada vedeam in mai multe posturi (in threadurile cu atestatele) ca se foloseste: SELECT .... INTO CURSOR NumeCursor si ma miram de ce unii folosesc asa cand se poate crea si cu Views direct din VFP... Views pe care apoi le setezi la RecordSource-ul gridului... Stiu ca este si RecordSourceType care are 4-SQL Statement... ma gandesc ca si asa se poate foarte usor folosi aceasta posibilitate ... poate ca asa ar trebui sa ajung sa lucrez si eu... Multumesc pentru ajutorul Dvs. Ovidiu Dobie  5/20/2010 1:32:18 PM Daniel Buduru 2335 posts Re: Updatare tabele ale unei baze de date dintr-o aplicatie  (N/A)  Vad acum ca, de fapt, n-am raspuns la problema modificarii structurii cu ALTER TABLE. Functioneaza, asa cum se poate vedea ruland textul urmator: CREATE TABLE test (f1 c(10), f2 i, f3 t) lcstr='1234567890ABC'  FOR i=1 TO 100 INSERT INTO test (f1, f2, f3) VALUES (lcstr, i, DATETIME()) next BROWSE LAST ALTER table test alter COLUMN f1 c(8) BROWSE LAST ALTER table test alter COLUMN f1 c(8) add COLUMN f4 l BROWSE LAST In ceea ce priveste utilizarea view-urilor, ai perfecta dreptate, e mult mai comod sa lucrezi cu un view actualizabil decat cu select in cursor si update. La atestate insa, nu se putea pune problema de a lucra cu view-uri din cauza nivelului de la care s-a pornit. Am folosit view-uri pentru actualizari de la vfp3 si pana cand a aparut cursoradapter-ul - care e, la randul lui, mult mai comod de folosit decat view-urile ... Ambele, si view-urile actualizabile si cursoradapter-ul, genereaza comenzi sql - insert, update, delete - pentru a actualiza tabela sursa.  Doar ca o fac mai rapid si mai eficient decat se poate face in cod. Contrar unei pareri destul de raspandite, comenzile update generate actualizeaza doar campurile modificate, si nu toate campurile actualizabile. Referitor la utilizarea unui select in grid.recordsource apare o problema: coloanele sun adaugate dinamic, in functie de ce returneaza selectul, si nu pot fi definite in design time. O aplicatie care foloseste view-uri pentru actualizrea tabelelor poate fi usor trecuta cu baza de date pe un server SQL - se folosesc aceleasi view-uri, doar altfel definite in baza de date. N-as recomanda insa view-urile in vfp9, cursoradapter-ul e mult mai flexibil. Iar cursorul returnat de un cursoradapter raspunde la requery, tableupdate si tablerevert la fel ca si un view, si poate fi parametrizat la fel ca si un view. VFP ofera posibilitatea parametrizarii comenzilor sql, iar aceasta permite scrierea unor comenzi generice, in care conditiile de filtru sa fie preluate din variabile in momentul executiei. Pea aceasta se bazeaza de fapt view-urile actualizabile  si cursoradapter-ul. Un exemplu de comanda parametrizata - folosind tabela test creata anterior lcSQL='SELECT * from test where f2=?pnI' pni=3 &lcsql pni=10 &lcsql Cu un view sau cursoradapter construit cu o astfel de comanda e suficient sa setezi variabila si sa faci un requery() pe cursorul respectiv pentru a-l ppula cu noile valori. Nu e nevoie sa se scrie din nou comanda si nici sa se faca tot felul de artificii pentru a include in comanda select continutul variabilelor respective. Folosind table buffering, controalele pot fi legate direct la campurile cursorului, prin controlsource, asa cum a fost prevazut sa lucreze ele, si nu prin preularea valorii din control.value si manipularea ei prin cod pana sa ajunga tot acolo: in campul din cursor. Iar utilizatorul poate sa stea pe un formular si o zi intreaga, sa greseasca la fiecare camp fara sa-i dea cineva peste mana si sa nu-l lasa se treaca mai departe - nici chiar cu escape - pana nu pune acolo o valoare corecta - pe care, de fapt, nu o stie. Abia in momentul cand cere salvarea, se verifica fiecare camp si conditie in parte, i se prezinta lista cu neconformitati si optiunea de a reveni in editare pentru a corecta erorile sau de a abandona editarea. Totul se petrece pe o copie a tabelei, nu se scrie nimic in baza de date pana nu e ok, si nici nu se blocheaza lucrul celorlalti pana cand utilizatorul isi termina editarea. Iar din punct de vedera al programarii, se reduce la cateva comenzi: requery, refresh, tableupdate sau tablerevert ... Daniel Buduru  5/26/2010 10:55:52 AM Ovidiu Dobie 105 posts Re: Updatare tabele ale unei baze de date dintr-o aplicatie  (N/A) Referitor la prima parte a postului: Am incercat un update la o tabela *.dbf dar nu reusesc cu alter table deoarece imi zice "database is invalid. Please validate" Daca pun linia VALIDATE DATABASE inainte de ALTER TABLE imi da eroarea "The fields in table ....*.dbf did not match the entries in the database" deja nu mai stiu cum sa fac... Specific ca testele le fac intr-un folder unde am baza de date de la client si acolo pun exe-ul nou compilat care contine un buton  "update" pe un form si in codul asociat acelui buton am pus: OPEN DATABASE numedb EXCLUSIVE VALIDATE DATABASE RECOVER CLOSE DATABASES USE facturi_tr ALTER TABLE facturi_tr ADD COLUMN plata I USE Ma puteti ajuta cu o idee... Ovidiu Dobie  5/26/2010 11:10:31 AM Daniel Buduru 2335 posts Re: Updatare tabele ale unei baze de date dintr-o aplicatie  (N/A)  Eroarea de la validare - "The fields in table ....*.dbf did not match the entries in the database" - spune ca tabela nu corespunde cu baza de date. Asa ceva se intampla atumci cand o tabela cu acelasi nume dar cu structura diferita - poate diferi chiar numai o litera intr-un  nume de camp sau ordinea campurilor sau o lungime de camp - este copiata din alta parte peste tabela originala. VALIDATE DATABASE RECOVER de obicei elimina din baza de date (dbc) ce nu corespunde cu cee in tabela. Mai sigura e detasarea si reatasarea tabelei la baza de date. Daca nu poate fi detasata - din cauza neconcordantei - se muta tabela din calea de acces, se valideaza database si se elimina tabela, apoi se ataseaza. Oricum, daca asta se intampla cu baza de date a clientului, inseamna ca e alterata iar actualizarea va esua si la el. Se poate ca cineva sa fi deschis atabela respectiva in Excel si sa fi modificat ceva in ea, si de aici neconcordanta cu baza de date. Baza de date de la client trebuie fie reparata, fie inlocuita cu una buna apoi importate datele din cea veche ... Daniel Buduru  5/26/2010 12:18:09 PM Ovidiu Dobie 105 posts Re: Updatare tabele ale unei baze de date dintr-o aplicatie  (N/A) Nu sunt probleme la baza de date a clientului ... Problema e la mine ca nu puteam sa fac alter table  ... stiam de ce primesc mesajul "The fields in table ....*.dbf did not match the entries in the database" ... dar nu stiam cum sa fac sa se poata realiza updatarea aceasta... Sper sa pot realiza detasarea tabelei cu DROP TABLE... Dar acum imi vine in minte ca eu am nevoie de datele din tabela facturi_tr ... si daca o detasez poate e mai complicat sa fac ALTER pe ea... Deci cred ca tot mai bine e sa fac cu importarea tuturor datelor din vechea baza de date in noua baza de date... in ordinea corespunzatoare, asa cum ai mai zis mai sus... pt. pastrarea integritatii referentiale... Ovidiu Dobie  5/26/2010 12:48:32 PM Daniel Buduru 2335 posts Re: Updatare tabele ale unei baze de date dintr-o aplicatie  (N/A) Atentie, DROP TABLE sterge si tabela de pe disc. Detasarea se poateb face din Project Manager - se selecteaza tabela, apoi butonul Remove - care intreaba daca doar o detaseaza sau o si sterge. In mod normal, ALTER TABLE functioneaza pe orice tabela, atat free cat si inclusa intr-o baza de date. In acest caz concret, nu functioneaza din cauza erorii din dbc, eroare care trebuie corectata. Detasarae si atasarea sunt necesare pentru a elimina eroarea din dbc, eroare care nu permite ALTER TABLE. Nu e necesara modificarea structurii pe tabela detasata. Da, importul este metoda singura, care corecteaza automat si aceste probleme. Daniel Buduru  5/26/2010 3:43:45 PM Ovidiu Dobie 105 posts Re: Updatare tabele ale unei baze de date dintr-o aplicatie  (N/A) Ai dreptate cu DROP TABLE ... dar la mine mi-ar trebui o comanda pt. detasarea unei tabele care sa fie executata din aplicatie, fara a mai instala mediul VFP la client... Totusi, e mai ok&elegant cu import ... voi studia mai mult optiunea cu importul, chiar am observat ca azi cineva a deschis un thread cu "transfer dintr-o tabela in alta"... Poate voi posta acolo daca voi avea nelamuriri... Multumesc pt. ajutor! Ovidiu Dobie  Page 1 of 1   Visual FoxPro  Cod, sintaxa si comenzi  Updatare tabele... Flat View Tree View Oldest To Newest Newest To Oldest