Search  
Friday, February 10, 2012 ..:: Forum ::.. Register  Login
 Forum Minimize
Pentru a putea posta mesaje trebuie să vă înregistraţi.
Notă: Mesajele cu conţinut jignitor sau ilegal (inclusiv cereri de soft piratat) nu sunt acceptate şi vor fi şterse imediat .

Pentru a primi raspunsuri rapide si corecte, scrieti in mesaj ce intentionati sa faceti, ce mesaj de eroare primiti, in ce context si in urma caror actiuni. De asemenea, mentionati versiunea de FoxPro in care lucrati!
Dacă nu specificați versiunea, se consideră VFP 9.0 SP2.

SearchForum Home
  Visual FoxPro  Visual FoxPro in general  modul de salvar...
 modul de salvare a datelor
 
 10/16/2006 10:19:08 AM
User is offlinefxtech
109 posts
5th


modul de salvare a datelor
 (Romania)
eu peste tot folosesc aceeasi metoda...
adica am la control source la fiecare camp pus m.field .. si cand salvez dai append blank si gather memvar... dar cateodata am probleme din cauza asta.. si ma gandeam in modul urmator.. ca pot sa iau fiecare valoare de la toate campurile si sa dau replace field with thisform.textbox.value ... si ma gandeam daca e mai bine sa fac sau nu asa . sau cum faceam inainte.. voi cum salvati datele ?!
 10/16/2006 1:09:19 PM
User is offlineaflorin
838 posts
1st


Re: modul de salvare a datelor
 (Romania)
Eu nu cred ca exista un mod "corect" de salvare a acestor date si alte moduri "incorecte". Totul depinde de structura aplicatiei si a BD.

spre exemplu, varianta cu SCATTER MEMVAR, controlsource pe variabile si GATHER MEMVAR (prezentata de tine) este OK pe aplicatii mici, dar poate crea probleme cind aplicatia creste si apar cazuri de genul apelare un noemnclator din altul (cind se pot suprapune numele de variabile.

o alta varianta ar fi SCATTER NAME si GATHER NAME si controlsource in interfata la proprietatile obiectului create de scatter. Atita timp cit ai grija la numele obiectelor si la domeniul de vizibilitate, e super.

daca lucrezi cu BD, buffering si tranzactii, merge si varianta legarii controalelor direct la campurile din tabela, iar salvarea se va face direct prin inchiderea tranzactiei, in timp ce ROLLBACK iti asigura Renunt-ul.

este si varanta cu thisform.textbox.value dar ... nu stiu ce sa zic - pe o aplicatie mai mare mai ai si cimpuri in tabela care nu apar direct in interfata dar sunt a naibi de utile (ex flag-uri).

Florin Aparaschivei - Iasi
 10/16/2006 2:39:20 PM
User is offlinefxtech
109 posts
5th


Re: modul de salvare a datelor
 (Romania)
vruiam mai mult sa intreb de fapt daca nu e recomandat acest mod de salvare a datelor... pentru ca eu am inceput acum sa folosesc acest mod.. adica fiecare camp il salvez cu replace field with value ... mi se pare ca am mai mult control asupra programului .. si nu mai am 1000 de variabile existente de fiecare data in memorie.. nu stiu acuma daca ma avantajeaza sau nu fata de metoda cu scatter gather... dar de asta am si intrebat.. poate stie cineva mai bine.
 10/16/2006 5:45:37 PM
User is offlineedyshor
1450 posts
1st




Re: modul de salvare a datelor
 (Romania)
cu scatter name / gather name ai o singura variabila in memorie .. un obiect foarte manevrabil care poate avea 1000 de proprietati .. gandeste-te ca grupezi toate variabilele tale din scatter memvar / gather memvar intr-un singur loc (numele obiectului) .. si crede-ma .. e foarte manevrabil :)
 
o linie lunga de "insert into table (..) value (..)" sau "replace c1 with v1, .. cx with vx" .. o inlocuiesti cu un simplu "insert into table from name var_obj' sau 'gather from name var_obj'  :)
 10/17/2006 12:03:34 PM
User is offlineaflorin
838 posts
1st


Re: modul de salvare a datelor
 (Romania)
Varianta cu REPLACE field_name with thisform.textbox1.value mai are o problema, in opinia mea:
textbox-urile nu mai au controlsource, ceea ce inseamna ca nu stiu, in mod direct, ce tip de data vrei tu sa stochezi acolo. De aceea va trebui sa umbli pe la proprietatile Format si InputMask pentru fiecare textbox, astfel incat, de ex, userul sa nu poate introduce caractere alfanumerice intr-un textbox ce va ajunge pe un camp numeric din tabela.

Florin Aparaschivei - Iasi
 10/17/2006 12:11:52 PM
User is offlinefxtech
109 posts
5th


Re: modul de salvare a datelor
 (Romania)
deci sa inteleg ca replace ul nu isi prea are rost in aplicati cu multe campuri .. nu ?
 10/20/2006 1:17:06 AM
User is offlinewtfia
142 posts
5th


Re: modul de salvare a datelor
 (N/A)
Mai poti sa folosesti table buffering. Views. Daca lucrezi cu baze de date, nu tabele independente (free tables), ai tranzactii care iti ofera un plus de siguranta.

Sau ceva de genul:

In form.load():
USE BazaRemote
COPY STRUCTURE TO BazaLocala
(SELECT * FROM BazaRemote sau orice altceva vrei. Ideea e ca aduci structura bazei de pe server pe local, cu sau fara date)
USE IN BazaRemote

TextBox-urile au la ControlSource BazaLocala.field
Utilizatorul poate modifica ce vrea, lucreaza pe local in momentul asta, nu direct pe server. La salvare:
USE BazaRemote
APPEND FROM BazaLocal
(sau INSERT sau SCATTER/GATHER sau UPDATE sau...)

Daca renunta la ce a modificat/adaugat nu trebuie sa faci nimic, pe server nu s-a modificat. Eventual stergi bazele de pe local. Daca se ia curentul utilizatorul a pierdut datele, dar atat, nu a ramas cu jumatate de inregistrare modificata pe server. Eventual daca are mult de introdus poti sa recuperezi ce avea cand s-a luat curentul. Un fel de table buffering manual.
Avantajul e ca ai exact aceeasi structura a bazei ca si pe server. Cel putin aceeasi structura si aceleasi date care existau in momentul in care a inceput adaugarea. Structurile nu se schimba prea des. Datele se schimba. Daca folosesti ID-uri unice de exemplu, in functie de ce sistem folosesti poate va trebui sa verifici daca nu cumva id-ul pe care i l-ai dat tu exista deja.

Oricum, principalul lucru pe care il face vfp e sa adauge/modifice/stearga date. Ai mai multe modalitati de a face asta la dispozitie. Depinde ce ti se potriveste.
 10/20/2006 11:16:41 AM
User is offlineaflorin
838 posts
1st


Re: modul de salvare a datelor
 (Romania)
Ideea este OK, dar nu va sta in picioare pentru acele aplicatii/module unde se lucreaza in retea, iar mai multi useri actualizeaza acelasi modul. Practic tu vei tine pe local datele asa cum erau ele in momentul incarcarii form-ului si nu vei vedea nimic din ceea ce fac altii in acest timp.

Nu vreau sa ma gindesc ce s-ar intimpla la un modul de facturare, cind doi clienti cumpara acelasi (ultim) produs din stoc.

Florin Aparaschivei - Iasi
 10/22/2006 1:27:07 PM
User is offlinewtfia
142 posts
5th


Re: modul de salvare a datelor
 (N/A)
 aflorin27 wrote
Ideea este OK, dar nu va sta in picioare pentru acele aplicatii/module unde se lucreaza in retea, iar mai multi useri actualizeaza acelasi modul. Practic tu vei tine pe local datele asa cum erau ele in momentul incarcarii form-ului si nu vei vedea nimic din ceea ce fac altii in acest timp.

Nu vreau sa ma gindesc ce s-ar intimpla la un modul de facturare, cind doi clienti cumpara acelasi (ultim) produs din stoc.


Probabil nu am fost destul de explicit. Pe local nu aduc tot stocul. As fi nebun sa aduc pe local o baza de date de peste 50 de mega (sa zicem), plus index, de fiecare data cand cineva vrea sa faca o operatie. Cine ar cumpara asa ceva sau cine ar tine un asemena angajat ? Nu. Presupunand ca am o baza de date stoc.dbf si una iesiri.dbf, cand se adauga o iesire din stoc pe local aduc doar structura.

USE iesiri.dbf
COPY STRUCTURE TO iesiriLocal.dbf
USE iesiriLocal.dbf
APPEND BLANK

in loc de

USE iesiri.dbf
APPEND BLANK

iar form.text1.controlsource="iesiriLocal.codprodus" in loc de form.text1.controlsource="iesiri.codprodus" sau in loc de form.text1.controlsource="m.codprodus". Verificarile sunt aceleasi in toate cele 3 cazuri.
Un alt avantaj e ca text1 poate fi bazat pe o clasa a ta. Clasa respectiva are in Init un cod de genul

this.InputMask = REPLICATE("X", FSIZE(cFieldName, cTableName))

presupunand, bineinteles, ca e un camp de tip caracter, lucru pe care clasa il verifica. Daca schimb structura bazei, InputMask se schimba fara sa fie nevoie sa fac nimic altceva, ceea ce nu se intampla daca lucrezi cu variabile.
Nu e singura solutie si nu e solutia perfecta, sau cea mai buna, sau orice altceva de genul asta. Nu cred ca exista asa ceva, depinde de mediul tau de lucru. Am mai spus asta. Dar cred ca e o solutie mai buna decat folosirea variabilelor.

Tu cum faci ?
 7/5/2007 4:43:14 PM
User is offlineanca.horhogea
22 posts


Re: modul de salvare a datelor
 (N/A)

Solutia cu baza locala am folosit-o si eu si este perfect atata timp cat fiecare lucreaza in "patratica lui". Dar cand ajung la momentul salvarii pe server si am vreo 3 calculatoare (pentru inceput) care factureaza si ajung toate odata la acest moment, fac toate USE BazaRemote de pe server si asteapta salvarea datelor pe server (si se asteapta unul pe altul pana se salveaza datele la primul calculator, ca sa fie eliberata BazaRemote si sa aiba acces si al doilea calculator la aceasta baza de date si tot asa etc). Apoi daca mai vorbim si de o baza de date FPW26 de o marime de vreo 9 MB, inchipuie-ti ca plangi putin langa calculator pana se salveaza factura respectiva pe server.

Sper ca m-am facut inteleasa cu problema mea si as vrea un raspuns, o parere, un sfat cum as putea sa elimin aceasta intarziere in lucru.

 

 7/5/2007 5:03:13 PM
User is offlinedni
420 posts
2nd


Re: modul de salvare a datelor
 (N/A)

Nu ma pricep deloc la contabilitate, dar daca se lucreaza cu tabele locale cum se evita ca sa nu fie mai multe facturi cu acelasi numar ?

Cred ca solutia cea mai rapida este o singura tabela pe un server, cu fisiere index local.

 7/13/2007 9:54:57 AM
User is offlineanca.horhogea
22 posts


Re: modul de salvare a datelor
 (N/A)

Imi explici si mie mai in detaliu solutia aceasta : o singura tabela pe server si fisiere index local?

De exemplu problema mea ar fi urmatoarea: am tabela de incasari prin casa (in care introduc chitante). Aceasta tabela este folosita si in modulul de casa, prin care se introduc chitantele completate de mana, sau se fac stergeri sau modificari de chitante gresite (deci in momentul asta imi trebuie toata baza de date de pe server cu toate datele). In acelasi timp baza de date o folosesc la modulul de facturare automata cu chitante automate (deci trebuie introduse chitantele editate la imprimanta odata cu factura, moment in care accesez aceeasi baza de date de incasari prin casa). Daca facturarea merge toata ziua si accesez permanent casa, nu mai poate lucra nimeni in modulul de plati prin casa manual pentru ca imi blocheaza modulul de facturare (nu imi mai salveaza chitantele automate, baza de date fiind accesata de altcineva).

Care ar fi solutia mai buna: sa salvez aceste chitante automate in alta baza temporara sau locala si sa le duc pe server intr-un moment cand baza de pe server nu este folosita de nimeni... sau daca imi spui mai detaliat ce inseamna fisierele index local si ma ajuta cu ceva, poate incerc.

 

 

 7/13/2007 10:14:33 AM
User is offlineDorin Vasilescu
1366 posts
1st




Re: modul de salvare a datelor
 (N/A)
Solutia ar fi accesul partajat la tabela cu blocarea acesteia doar la salvarea datelor (de pe oricare din statii ) cu FLOCK().
In timpul cat este blocata tabela se ia ultimul numar, se incrementeaza si se inlocuieste in tabela .
 
 7/13/2007 4:47:12 PM
User is offlinedni
420 posts
2nd


Re: modul de salvare a datelor
 (N/A)

Pai Dorin ti-a dat raspunsul ca la carte si care se foloseste uzual. Eu personal folosesc nu numai o tabela pe server ci mai multe (cite am nevoie), deschise SHARED. Lucrul in baza temporara mi se pare cam nesigur. Eu as face cum a zis Dorin. Eu personal folosesc in acest caz folosesc o tabela pe server care tine numai numere, id-uri unice etc...si care nu poate fi accesata decit exclusiv de catre useri, deci ceilalti stau la coada in niste bucle pina pot deschide baza exclusiv  cu un mesaj de genul "Network buzzy". Oricum chestia dureaza maxim 5 secunde la 50 useri care acceseaza in acelasi timp...In principiu la lansarea programului deschid tabelele si creez la fiecare user indecsi (cu set index) pe hard-disk-ul local...(cind ies din program se sterg). Daca tabela este "grasa", dureaza ceva dar merita...

 

  Visual FoxPro  Visual FoxPro in general  modul de salvar...

Search  Forum Home         

 Google Ads Minimize

    

Copyright 2002-2010 Profox   Terms Of Use  Privacy Statement