Search  
Sunday, August 09, 2020 ..:: 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  Baze de date, tabele, view-uri si indecsi  unire tabele in...
 unire tabele intrari si iesiri
 
 4/6/2011 11:36:13 PM
User is offlinebata01yu
60 posts


unire tabele intrari si iesiri
 (N/A)
Buna,
Apelez din nou la ajutorul vostru spre nestiinta mea
Am doua tabele intrari si iesiri
la tabela intrari printre altele am si campurile
prod_cod, prod_id, cant, p_u, doc_nr, data_in

la tabela iesiri
prod_cod, prod_id, cant, p_u, bc_nr, data_bc

si as vrea sa obtin o tabela prin unirea celor doua
ceva de genul

prod_cod, prod_id, intrari, iesiri, p_u, doc_nr, data_in, bc_nr, data_bc
cu toate inregistrararile din cele doua tabele,
Mentionez ca am obtinut rezultatul dorit prin scan si insert, dar m-ar interesa daca as putea sa obtin acelasi rezultat si prin select.
Cu multumiri.
P.S. folosesc vfp9


 4/7/2011 8:44:43 PM
User is offlineDaniel Buduru
3522 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
Select prod_cod, prod_id, cant as intrare, cast(0 as N(10,2)) as iesire, p_u, 'INT' as doc, doc_nr, data_in as data ;
From tabela_intrari ;
Union ;
Select prod_cod, prod_id, 0 as intrare, cant as iesire, p_u, "BON" as doc, data_bc as data ;
From tabela_iesiri ;
Order by 1, 8 ;
into cursor intrari_iesiri

Daca vrei sa tii coloane separate cu data_in si data_bc, modifica selectul de mai sus in mod corespunzator.


Daniel Buduru
 4/11/2011 9:16:54 AM
User is offlineMihai ov
20 posts


Re: unire tabele intrari si iesiri
 (Romania)
Daniel vad ca te pricepi la baze de date Da-mi o ideie cum descarci o gestiune si cum formezi (actualizezi) un fisier de stocuri Actualmente lucrez cu un fisier de stocuri format ceea ce ma nemultumeste( am scapari de inregistrari din cauza actualizarilor) As vrea sa lucrez cu o situatie ce actualizeaza o singura inregistrare de ex: id1_cantitate - id1.iesiri = id1_stocFinal_1 id1_stocFinal_1 - id1_iesiri= id1_stocFinal2 ....etc Ai lucrat asa (de la 1.000.000 de inregistrari in sus ?) As vrea sa stiu viteza de executie aprox.. la cererea stocului sau daca ai ceva idei de rutine scrise pe server ( sql Server ) Am de ales din mai multe variante teoretice dar nu am la nici una cu experienta functionala. Multumesc
 4/11/2011 10:36:01 AM
User is offlineDaniel Buduru
3522 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
Eu lucrez cu un fisier de tranzactii -  de fapt, doua tabele, header si pozitii - in care inregistrez documentele de intrare si iesire.
Tabela header cuprinde minim id document, tip document, numar document, data document, data operare in stoc (datetime, daca se lucreaza in timp real), gestiunea creditoare, gestiunea debitoare.
Tabela de pozitii cuprinde (printre altele) un id document, prin care se leaga la header, id articol, intrare, iesire, valoare, id gestiune . Cand tranzactia reprezinta un transfer intre gestiuni, se creeaza automat (in trigger) inregistrarea complementara, astfel incat sa existe o iesire dintr-o gestiune si o intrare in cealalta gestiune.
Mai tin o tabela de stoc curent, actualizata printr-un trigger after insert, update, delete pe tabela de tranzactii. Structura tabelei (minima) cuprinde id articol, id gestiune, intrari, iesiri, valoare intrari, valoare iesiri, valoare stoc si  id document, data operarii pentru ultimul document operat.
Tabela de stoc poate fi verificata si/ sau creata in orice moment ca suma de intrari - iesiri pe tabela de tranzactii.
Pentru documentele care se arhiveaza (nir, facturi) exista tabele separate, care actualizeaza tabela de tranzactii prin trigger.
Oricum, orice document este inregistrat o singura data in sistem, redundanta (acolo unde este necesara) fiind realizata prin trigger.
Daca se lucreaza cu rezervari (vanzare cu facturare prealabila de la mai multe puncte pe acelasi stoc), lucrurile se mai complica putin :)
Evident, ceea ce am descris functioneaza pe un server sql.
Se lucreaza in timp real, indiferent cat de mare este numarul de inregistrari din tabela de tranzactii.



Daniel Buduru
 4/11/2011 1:29:40 PM
User is offlineMihai ov
20 posts


Re: unire tabele intrari si iesiri
 (Romania)
Eu tot asa cu fisier de stoc lucrez doar ca actualizarea nu o fac din tranzactii asa ca sunt expus la greseli de operare cumulate de la inventar la inventar . Ex din bonuri imi da cateodata eroare din cauza multitudini de drivere la casele de marcat
Lucrez doar in retea inclusiv vpn pentru unele situati prin internet.

Acum
Vreau sa trec datele in sql server

Ma gandeam sa folosesc o tabele tip balanta cu tranzactile cu indexul id_produs descrescator asfel ca la solicitare sa fie primul id gasit (id articol, sold ,intrare, iesire, valoare, id gestiune,ultimul_furnizor ....)
Sunt raspunzaror de datele clientului de la ultimul inventar asa ca ar trebui sa primesc stocul din tranzactii in timp real pe un id de la ultimul inventar (plus o rutina prin care sa verific corectitudinea datelor respectiv daca nu sa omis o tranzactie)
Aici se adauga rezervarile de nr_doc si catitati
Folosesc coduri de bare asa ca introducerea din bonuri e cam 0.5 s / produs
Vad ca tu folosesti un heder pe tranzactii ( ai ceva avantaje ?)

daca ai recomandari la astept
multumesc
Mihai

 4/11/2011 2:24:21 PM
User is offlineDaniel Buduru
3522 posts
1st




Re: unire tabele intrari si iesiri
 (N/A) Modified By Daniel Buduru  on 4/11/2011 2:32:41 PM)
Nu poti tine asa ceva pe tabele dbf ... Trebuie sa treci pe un server sql.

Toate documentele care permit mai mult de o singura pozitie au o parte de date comuna, date care se tin in header. Intre header si pozitii este o relatie 1-to-many. E neeconomic sa inregistrezi aceleasi date pe fiecare din pozitiile unui document.
In tabela de tranzactii, gestiunea din pozitii este necesara pentru transferuri intre gestiuni - aceeasi pozitie din document apare de doua ori, o data ca iesire din gestiunea care elibereeza si apoi ca intrare in gestiunea care primeste.

Tin fisier separat pentru inventar, desigur tot doua tabele, header si pozitii. O inregistrare din tabela pozitii are id articol, id gestiune, stoc scriptic, stoc faptic. Stocul faptic, si nu diferenta dintre stocul faptic si cel scriptic.
Inventarul este replicat in tranzactii, tot prin trigger, iar inregistrarea de inventar are pe iesire stocul scriptic, iar pe intrare stocul faptic.
O rutina poate verifica daca stocul calculat anterior inventarului este egal cu cantitatea iesita din inregistrarea de inventar. Daca valorile nu corespund, inseamna ca s-au adaugat/ modificat/ sters inregistrari anterioare datei inventarului. Situatie nu rar intalnita, cand nu s-au operat la timp documente de miscare (nir, stornari, etc) si se opereaza cand le vine randul ... Evident, se poate pune o restrictie in baza de date, care sa nu permita inregistrarea documentelor anterioare ultimului inventar.

Daca se lucreaza cu o header, se poate tine o suma de control a documentului in header, eventual si numarul de pozitii, ceea ce permite verificarea rapida a documentelor inregistrate.

Stocul curent este calculat si actualizat dupa fiecare tranzactie. Cum am spus, asta se face in trigger. Se actualizeaza tabela de stocuri cu stoc curent+ intrare - iesire, pentru id articol si id gestiune. Nu ai nevoie sa calculezi o suma pe articol si gestiune dupa fiecare tranzactie.

In sql indexul descrescator (sau crescator) nu conteaza, se regaseste un set de inregistrari dupa anumite criterii, nu dupa pozitia inregistrarii in tabela. In sql nu exista notiunea de inregistrare (record) ci de linie. Cronologia inregistrarilor (liniilor) se stabileste prin valoarea unui camp, nu prin pozitia in cadrul tabelei.
Limbajul sql implementat pe serverele sql este mult mai complex decat cel implementat in vfp si permite regasirea, gruparea, ordonarea datelor mai usor decat in tabelele dbf.
Corelarile implementate in triggere asigura integritatea bazei de date. Chiar daca se opereaza modificari direct asupra bazei de date, tabelele calculate vor reflecta mereu datele din tabelele sursa.

Treci pe server sql, fa-ti un model al bazei de date si incepi o simulare.
Daca faci interfata in vfp, iti recomand sa lucrezi cu cursoradapter pentru actualizarea bazei de date. E foarte posibil sa poti trece aplicatia existenta sa lucrezeclient-server.
Ai interesul ca fiecare tabela sa aiba o lungime cat mai mica a inregistrarii. Obtii o crestere de viteza in felul asta.
Toate datele pe care vrei s ale treci intr-un tabel de tip balanta se pot regasi prin interogari. Nu ai interesul sa lucrezi pe o astfel de tabela. Trebuie sa vezi cand ai nevoie de toate datele de acolo, si cat de repede iti trebuie. Daca le utilizezi la fiecare document introdus, e util sa le tii gata calculate. Daca iti trebuie doar la raportari, sau cand vrea cineva sa stie ce marfa are de la un furnizor, nu e cazul sa le tii gata calculate.
Orice operatie se face in trigger, se face la orice linie introdusa sau modificata. Daca ai prea multe operatii aici, poti ingreuna lucrul. Exista utilitare care iti pot da informatii asupra costului (in timp) al fiecarei rutine, select, etc. Poti optimiza baza de date si aplicatia cu ajuorul lor.



Daniel Buduru
 4/11/2011 3:32:47 PM
User is offlineMihai ov
20 posts


Re: unire tabele intrari si iesiri
 (N/A)
Mai am cateva aplicatii relationale scrise chiar si pe sql (facturari automate , Casa de amanet, si alte zeci mai mici)
Gestiunea tot o incep de cativa ani si tot o aman pentru ca vreau sa o scriu cu adevara bine cu zecile de pretentii de la clienti acumulate in 12 ani
Problema e ca poti porni gresit si sa te trezesti peste 2 ani cand nu mai ai ce face. Acum, daca ai un exemplu de baza de date intrari iesiri pe sql ex: receptii+facturare+catalog sau daca vrei sa ma indrumi sau sa colaboram sa-mi zici . eMail pentru_mihai@yahoo.com

Nu vreau sa ma opresc la gestiune..
Scrie pe email ce poti sa-mi oferi
Am scris cod putin in c# vb sql direct in api-uri xml dar cel mai mult vfp

Eu sunt adeptul "nu mai descoperi inca odata lumea"
 4/12/2011 12:31:53 AM
User is offlineEugen Gliga
2178 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
 Daniel Buduru wrote
Eu lucrez cu un fisier de tranzactii -  de fapt, doua tabele, header si pozitii - in care inregistrez documentele de intrare si iesire.
Tabela header cuprinde minim id document, tip document, numar document, data document, data operare in stoc (datetime, daca se lucreaza in timp real), gestiunea creditoare, gestiunea debitoare.


Salut, Daniele,

Intervin si eu in aceasta discutie, deoarece sunt exact in faza de proiectare a bazei de date pt trecerea aplicatiei de gestiune pe arhitectura client-server. Tranzactiile le-am tinut si eu ca si tine in doua tabele header si detail si totul e ok. Pt stocuri am tinut un fisier redundant, mai exact pe fiecare pozitie aveam pe langa datele de identificare ale documentului si articolului,  cantitatea intrata sau iesita in document, totalintrari si totaliesiri, stocul fiind evident egal cu totalintrari-totaliesiri. La fiecare operatie adaugata in fisierul de tranzactii inseram o pozitie in fisierul de stocuri si recalcualm total intrari si total iesiri de la pozitia curenta pana la ultima pozitie. Fisierul de stocuri putea fi refacut oricand din fisierul de tranzactii, dar operatia in unele cazuri putea sa dureze mult.Tinand cont ca structura fisierului de stocuri a fost gandita prin anii '90 pt dbase IV, a rezistat bine pana acum. Acum, cand reproiectez baza de date vreau sa fac un fisier de stocuri in genul celui descris de tine mai exact sa nu mai tin in el si istoricul operatiilor pe care il am dealtfel in fisierul tranzactii-detail. Probabil ca descrierea facuta de tine a fost una simplificata.Pt mine fisierul de stocuri trebuie sa fie organizat pe articol, pret, lot, data expirare si data intrare. Adica trebuie sa am in orice moment stocul atat total pe articol cat si detaliat. Cand fac un document de iesire ( bon consum sau factura) art trebui sa pot automat sa aleg, cantitatea  dupa Lot, Dataexpirarii, Data intrarii si Pret sau pur si simplu sa-i specific ce vreau sa descarc. Nu cred ca asta ar fi o problema la actualizarea fisierului de stocuri dupa fisierul de tranzactii. Cazurile unde am avut probleme de care vreu sa scap in noua versiune, sunt cele legate de modificarea sau stergerea unor documente. Modificarea unui document presupune recalcularea stocului atat la inceputul editarii documentului cat si la salvarea lui, lucru care poate dura ceva timp. Un alt caz care mi-a ridicat probleme este faptul ca firma vinde o perioada fara sa faca receptia, iar apoi dupa receptia, trebuie recalculate stocurile. Poate poti sa-mi dai niste sfaturi referitor la organizarea fisierului de stocuri, in concordanta cu cerintele de mai sus.

 4/12/2011 3:06:15 AM
User is offlineDaniel Buduru
3522 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
Descrierea e foarte mult simplificata.
Intr-adevar, modificarile documentelor consuma cele mai multe resurse ...
Eu am rezolvat problema prin stornarea pozitiei initiale si inregistrarea pozitiei modificate. Evident, doar in cod, nu prin documente.
Daca intrarile se inregistreaza post-factum, stocul curent e inutil. Daca e vorba doar de indisciplina, se rezolva prin eliminarea de la selectie a articolelor cu stoc 0. Doar ca, de obicei, nu tine de indisciplina operatorului, ci de politica firmei ...
Stocul curent se tine fara probleme chiar si in aceasta situatie, dar altfel se pune problema la calculul pretului mediu ponderat, a valorii stocului, etc. In aceasta situatie, orice situatii care reflecta valoare stocului, rulaje, adaosuri, e mai bine sa fie disponibile doar dupa inchiderea contabila a perioadei.

Eu permit stergerea unui document intr-o singura situatie: documentul nu s-a tiparit, este ultimul document inregistrat, iar de la inregistrare nu a trecut inca un termen limita. Daca nu sunt indeplinite aceste conditii, documentul poate fi doar anulat, ramanand in baza de date.
Documentul anulat este stornat din stoc, la fel ca si un document sters, si este exclus din selectie atunci cand se calculeaza totaluri pe tabela respectiva.

Pentru preturi, tin o alta tabela in care se inregistreaza fiecare intrare si valoarea ei, stocul si valoarea stocului inainte de intrare, stocul si valoarea stocului dupa intrare si pretul mediu ponderat dupa intrare.

Pentru loturi, lucrez cu un id articol extins, compus din id articol si id lot. Pentru articolele declarate cu lotizare, stocul se tine pe acest id (articol /lot). Data expirarii este un atribut al lotului, se poate include in filtre si se poate ierarhiza stocul in functie de asta.
Problema cea mare la lotizare este insa corectitudinea operarii cu loturile. Doar doi dintre clientii mei opereaza efectiv cu ele, lotul fiind inscris in documente. Ceilalti care au cerut lotizare au vrut doar sa arate ca au asa ceva in sistem, dar inventarul arata ca lotul s-a operat fictiv.

Tin istoricul modificarilor intr-o baza de date separata, alta decat baza de date a aplicatiei. La orice modificare / stergere se insereaza  in log o linie cu  continutul inregistrarii inainte de modificare.

In toate tabelele am doua campuri in care tin impachetata data si ora crearii si a ultimei  modificarii a inregistrarii.

Pe server lucrurile se schimba mult fata de dbf. Faptul ca toate datele redundante sunt operate in triggere si fac parte din acceasi tranzactie de actualizare face inutile anumite precautii luate cand s elucreaza cu dbf-uri.
Actualizarea tranzactionala este obligatorie, iar documentele sunt comise in baza de date doar la sfarsitul editarii lor, nu fiecare pozitie in parte.
Daca se cere un control rigurso al stocului si e prohibita emiterea documentelor pe stoc negativ, se pot pune constrageri in baza de date, constrangeri care sa nu permita salvarea documentului in acest caz. O varianta este sa se salveze cu cantitatea existenta pe stoc, dar documentul sa fir marcat ca asteptand decizia utilizatorului si sa prezinte distinctiv pozitiile la care stocul a fost insuficient. Daca nu este acceptat astfel, documentul poate fi sters.

In functie de limbajul sql al serverului, unele operatii se fac mai simplu pe unele servere, altele mai complicat.
Running total (sold precedent - sold final) este un loc in care mai toate serverele se impiedica ... Cel mai simplu se face in vfp, cu doua instante ale aceluiasi tabel si cu relatie pe recno()-1 intre ele, si o comanda replace all ...Pana acum, doar in sql server 2008 am gasit o solutie la fel de rapida ca in vfp.

Nu prea stiu ce sa-ti spun despre tabelele de stocuri, altceva decat am spus pana acum. Poate doar daca am discuta pe cazul concret, asta insemanand si precizarea serverului, pentru a tine cont si de posibilitatile limbajului.

Daniel Buduru
 4/12/2011 10:48:21 PM
User is offlineDumitru
206 posts
4th


Re: unire tabele intrari si iesiri
 (N/A) Modified By Dumitru  on 4/12/2011 10:54:58 PM)
Scuze, intervin si eu, problema este importanta si ma intereseaza.
Ma intereseaza ce date redundante trebuie sa tinem in db cu referire la o aplicatie de gestiune, una care sa ia in considerare toate metodele de evidenta (la alegerea utilizatorului FIFO, LIFO, Pret mediu ponderat, pret de catalog) si cum o structuram.
Am vazut ca pe langa tabela de tranzactii Daniel tine si o tabela pentru inventar, buna treaba, am inteles avantajele:
- este un bun punct de introducere a stocului si soldului initial;
- se ingheata starea la un moment dat (pentru ca utilizatorul a pierdut stocul din mana);
- se realizeaza inventarele curente avandu-le oricand asa cum au fost la momentul lor;
- se poate determina daca au fost operate documente anterioare momentului inventarului si se poate interzice tranzactia;
Probabil mai sunt si altele, n-am vazut dezavantaje in afara de faptul ca, pentru mine, a aparut o tabela pe care trebuie sa o gestionez. (asta nu-i dezavantaj fata de alte structuri).

S-a vorbit pana acum de o structura:
STOCURI
(tabela calculata)

TRANZACTII
(detalii)

TRANZACTII
(antet)

Nu ma prind unde este locul tabelei inventar, ce legaturi are si cu cine ? Cat de complexe devin interogarile SQL daca trebuie sa ignor (in calcule) tot ce este inainte de inventar?




 4/13/2011 12:35:56 AM
User is offlineEugen Gliga
2178 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
 Daniel Buduru wrote
Nu prea stiu ce sa-ti spun despre tabelele de stocuri, altceva decat am spus pana acum. Poate doar daca am discuta pe cazul concret, asta insemanand si precizarea serverului, pentru a tine cont si de posibilitatile limbajului.


Deocamdata mi-ai spus suficient. Trebuie sa aprofundez si daca ma lovesc de ceva concret o sa te intreb.
La genul meu de clienti nu prea tine treaba cu stornarea documentului ca s-ar tripla fisierele de tranzactii. Eu pana acum am folosit o politica de recuperare a inregistrarilor sterse pt a evita crestrea excesiva a bazei de date. In privinta stocurilor eu sunt foarte tolerant, ii las sa vanda pe minus daca vor asta si sa-si corecteze stocul cad vor prin receptie sau stornare de la un cod si mutare la alt cod sau prin lista de inventar. Intradevar situatiile reale vor fi disponibile doar la sfarsitul periodei, dar stocul tot e util chiar daca e doar cantitativ sau negativ.  Pe unii ii intereseaza doar iesirile intro anumita perioada pt a putea face comenzi. Ma gandesc, pt flexibilitate sa permit orice operatie, stergere sau modificare, dar gradat in functie de drepturile userului si oricum voi memora orice operatie intr-un fisier log. Referitor la lot, intradevar, data expirarii este un atribut al lotului, dar am si cazuri in care nu intereseaza lotul ci doar data expirarii. In acest caz daca nu preiau lotul, tot stocul va fi pe acelasi lot si nu stiu cum o sa mai pot sti stocul pe data expirarii. Asta este un caz particular utilizat mai ales la magazine sau depozite cu marfuri perisabile. Si la mine doar doua firme lucreaza corect cu loturi si asta doar pt ca sunt obligate iar eu pot sa zic ca am introdus aceasta facilitate in program tot pentru ca am fost obligat. E vorba despre medicamente si despre produse din carne unde trebuie sa existe trasabilitate. Dupa ce finalizez in mare structura bazei de date probabil ca va trebui sa fac ajustaje in functie de posibilitatile de implementare pe server. Mutumesc pt informatii

 4/13/2011 2:41:45 AM
User is offlineEugen Gliga
2178 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
Solutia ta din VFP cu doua instante ale aceluiasi tabel si cu relatie pe recn()-1 este foarte tare. Eu ma gandeam ca e doar un artificiu pt VFP si ca serverele stiu sa  faca treaba asta nativ.
 4/13/2011 4:48:02 AM
User is offlineDaniel Buduru
3522 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
 Dumitru Echim wrote
S-a vorbit pana acum de o structura:
STOCURI
(tabela calculata)

TRANZACTII
(detalii)

TRANZACTII
(antet)

Nu ma prind unde este locul tabelei inventar, ce legaturi are si cu cine ? Cat de complexe devin interogarile SQL daca trebuie sa ignor (in calcule) tot ce este inainte de inventar?

Tabelele implicate in stocuri sunt urmatoarele:
Articole
Gestiuni
Preturi
NIR - header si detalii
Loturi - header si detalii
Inventar - header si detalii
Facturi vanzare - header si detalii
Tranzactii - header si detalii
Stoc curent
Intrari-preturi - pump, fifo, lifo
In tranzactii se inregistreaza direct documentele interne - bonuri de consum, note de predate, bonuri de transfer, dispozitii de livrare/avize.
Inregistrarile din nir, inventar, facturi vanzare sunt replicate in tranzactii.
In tranzactii se regasesc absolut toate miscarile de stoc.
Fiecare tabela header are (minim) id document, tip, numar, data document, data inregistrarii in stoc, gestiune creditoare, gestiune debitoare.
Fiecare tabela detalii are (minim) id document, id inregistrare, id inregistrare pereche (pentru transfer intre gestiuni), idarticol, um, intrare, iesire, pu, valoare
Tabela detalii nir are (minim) id document, id inregistrare, articol, um, cantitate, pret, cu datele furnizorului, si id articol, um, pret cu datele de receptie.
Toate documentele care se tiparesc / arhiveaza se pastreaza in baza de date in forma in care au fost tiparite, si nu mai pot fi modificate dupa imprimare. Desigur, se poate debloca, dar numai la un anumit nivel de acces.

Interogarile sql sunt, de multe ori, foarte complexe. Nu complexitatea lor afecteaza performantele, cat organizarea datelor. Un server sql este altceva decat o baza de date cu tabele dbf. Pentru orice server exista instrumente de optimizare, la unele incluse in distributia standard, la altele separat sau third-party.
Query execution plan, client statisctics, server profiler permit evaluarea si compararea performantelor fiecarei proceduri, interogari, si orice se mai face pe server.
Este simplu sa testezi mai multe variante, si de structuri si de cod, si sa compari consumul de resurse si viteza de executie pentru fiecare varianta in parte.

Daniel Buduru
 4/13/2011 4:49:52 AM
User is offlineDaniel Buduru
3522 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
 Eugen Gliga wrote
Solutia ta din VFP cu doua instante ale aceluiasi tabel si cu relatie pe recn()-1 este foarte tare. Eu ma gandeam ca e doar un artificiu pt VFP si ca serverele stiu sa faca treaba asta nativ.


In sql running total se face cu un cursor, parcurs secvential cu o comanda echivalenta unui scan. Se calculeaza valorile apoi se actualizeaza tabela. Operatia este consumatoare de resurse si devine lenta la un numar mare de inregistrari.
In ms sql server 2008 s-a introdus, printre altele, si parcurgerea in ordinea unui index la executia comenzilor select, update. In combinatie cu un index clustered (liniile tabelei sunt stocate in ordinea indexului), se poate obtine un running total printr-o singura comanda update. Un index poate fi ordonat dupa mai multe campuri, fara a fi necesara concatenarea lor intr-o singura expresie, asa cum e cazul in vfp.

update dbo.sstock
    set @StockPrev = stock = @stockPrev+ss.qty_in-ss.qty_out
    from erp.dbo.sstock ss with (INDEX(ix_sstock))

Comanda completa calculeaza stocul, pump, pu fifo pe articol si gestiune. Timpul de executie, pe aceeasi tabela, fata solutia clasica cu cursor este cu cateva ordine de marime mai mic.

In ceea ce priveste stornarea unei inregistrari, este unul din cele doua moduri in care se face actualizarea in sql: sql update sau detele + insert. cand se sterge o inregistrare din tabela de tranzactii, in tabela de stoc curent se opereaza tranzactia cu minus. Cum tabela are o singura inregistrare pemtru un articol si o gestiune, stornarea nu afecteaza cu nimic dimensiunea tabelai.

In sql refolosirea unei inregistrari nu are sens. Serverul reutilizeaza spatiul ramas liber in urma stergerii unei inregistrari.

Referitor la lot, eu tin un tabel separat cu loturile de receptie, unui lot fiindu-i asociate mai multe informatii, printre care lotul furnizorului (unde exista), data producerii, data expirarii, si altele, in functie de cerinte. In tabela de tranzactii apare doar id lot.
Chiar daca lotul nu intereseaza, ci doar data expirarii, e mai eficient sa se genereze automat un lot, decat sa se lucreze cu algoritmi diferiti. Oricum, daca nu se opereaza loturile, informatia cu data expirarii nu are cum sa fie valida ...  stocul scriptic cu un anumit termen de valabilitate nu va fi nicodata la fel cu cel fizic ...
In functie de ce vrea utilizatorul sa vada, i s epoate arata un numar de lot sau un termen de valabilitate, sau ambele, informatia este luata din acelasi loc si se opereaza in acelasi mod.

In sql combinarea informatiei din mai multe tabele este mult mai eficienta decat in vfp cu baza de date nativa. Viteza de lucru este mai mare cand se selecteaza campuri din 8-10 tabele decat daca toate aceste campuri sunt aduse in aceeasi tabela. La viteza de executie conteaza mult numarul de pagini de alocare explorate pentru a regasi informatia. In vfp, uneori e mai eficient sa existe un anumit grad de redundanta.


Daniel Buduru
 4/13/2011 11:37:52 AM
User is offlineDaniel Buduru
3522 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
Aici este un articol despre optimizare. Se poate vedea ce informatii pune la dispozitie in execution plan si cum se pot evalua diferite medtode de organizare a datelor si de interogare.
http://sqlblog.com/blogs/paul_white/archive/2011/02/23/Advanced-TSQL-Tuning-Why-Internals-Knowledge-Matters.aspx

Daniel Buduru
 4/13/2011 1:14:19 PM
User is offlineEugen Gliga
2178 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
Da, vad ca doar in ms sql server exista clauza With index la Update.

Sigur ca stornarea nu afecteaza dimensiunea tabelei de stocuri, dar ma refeream la tabela de tranzactii in sensul ca daca la o modificare de document in loc de stergere se face  doar anularea documentului, acesta ramane totusi in tabela, iar in caz de multe modificari dimensiune tabalei de tranzactii creste.

Referitor la loturi este o idee buna sa generez loturi automat la fiecare intrare noua pt a introduce data expirarii. Inteleg ce vrei sa zici cu faptul ca stocul scriptic nu va fi niciodata egal cu cel faptic, deoarece iesirile nu se opereaza pe lot, insa  optional operez iesirile in ordinea lotului. Personalul magazinului are grija sa expune marfa pe raft in ordinea datei de expirare. Oricum practica in magazine este de a nu scoate marfurile noi pana nu trec alea vechi indiferent ce mod de evidenta exista. Nu este o situatie exacta, dar daca le scot o lista cu produsele care urmeaza sa expire, ei verifica stocul si iau masuri ( ieftinire sau retur ).





 4/13/2011 1:59:32 PM
User is offlineDaniel Buduru
3522 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
 Eugen Gliga wrote

Sigur ca stornarea nu afecteaza dimensiunea tabelei de stocuri, dar ma refeream la tabela de tranzactii in sensul ca daca la o modificare de document in loc de stergere se face  doar anularea documentului, acesta ramane totusi in tabela, iar in caz de multe modificari dimensiune tabalei de tranzactii creste.



Nu asta inteleg prin stornarea tranzactiei: anularea ei si crearea unei inregistrari noi.
Prin stornare inteleg operatia inversa celei generate de document. Daca, sa zicem, se face o intrare de articol a in gestiunea g cu cantitatea q si pretul p, iar aceasta inregistrare se modificarea in articolul a1, gestiunea g1, cantitatea q1, in tabela de stoc curent se face mai intai o intrare de articol a in gestiunea g cu cantitatea -q, apoi se face din nou intrarea articolului a1, in gestiunea g1, cu cantitatea q1. E doar operatia facuta in trigger-ul tabelei de tranzactii asupra tabelei de stoc curent.
Aceeasi operatie - intrare cu -q - se face si in cazul stergerii inregistrarii.

Documentele deja tiparite nu se mai pot modifica. Indiferent de cererea clientului, eu nu vreau sa fiu pus in situatia de a mi se arata o factura care nu corespunde cu ceea ce se gaseste in baza de date.
Am avut de-a face cu incercari de frauda din partea angajatilor clientilor inca de la primele aplicatii implementate. Daca nu s-a putut modifica factura in baza de date, s-a procedat la modificarea cu mana pe factura tiparita a pretului sau cantitatii, la fel si pe chitanta emisa pentru acea factura, in speranta ca nu se mai uita nimeni pe hartii, ci doar in baza de date. Evident, suma predata la caserie corespundea valorii din baza de date, si nu valorii modificate pe chitanta.
Daca un client doreste sa-si modifice astfel de documente dupa bunul plac, nu are decat sa apeleze la alta firma.
Daca s-a constata o eroare dupa emiterea documentului, anularea documentului si emiterea unuia nou este singura modalitate legala.
Daca operatorul greseste sustinut, fie e cazul sa fie inlocuit, fie firma respectiva inca nu este pregatita sa aiba un sistem de gestiune informatizat.

Daniel Buduru
 4/13/2011 8:41:18 PM
User is offlineEugen Gliga
2178 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
Cu stornarea e clar. Te referi la faptul ca daca modifici un document faci doar o stornare in stocuri iar documentul original de fapt il stergi si generezi altul. Am crezut ca pe langa stornare pastrezi si versiunea originala a documentului intr-o forma neactiva sau mai generezi un documet storno care sa-l anuleze pe primul.

Referitor la posibilitatea de a modifica documente deja emise, asta tine de politica firmei. Intradevar ca daca mergi la o firma serioasa n-o sa accepte nimeni sa-ti modifice o factura tiparita. Parerea mea este ca programul trebuie sa fie flexibil si configurabil si daca beneficiarul cere asta in mod expres, ii dau voie sa faca ce vrea pe raspunderea lui. Am avut si eu situatii cu documente tiparite care nu corespundeau cu cele din calculator si de atunci scriu intr-un fisier log fiecare operatie efectuata asupra unui document, data, ora, ip si user. Operatorul trebuie sa fie constient ca orice operatie face, aceasta va fi memorata undeva. Deasemeni documentul tiparit ar trebui sa contina data si ora tiparirii scris undeva mic si discret.
 4/14/2011 1:13:57 AM
User is offlineDumitru
206 posts
4th


Re: unire tabele intrari si iesiri
 (N/A) Modified By Dumitru  on 4/14/2011 1:18:10 AM)
Am aruncat un ochi dar pana la optimizare mai am probleme la structura.
@Daniel,
*** Tabelele "Preturi" si "Intrari-preturi" Ambele au date redundante ? (cred ca sunt rezultatul experientei, te rog daca vrei sa detaliezi, ce contin)

*** In tranzactii am date amestecate, documente primare (integral) si date de pe alte documente replicate aici.
Nu pot sa fac upgrade de structura la un document fara a afecta si pe altele - cu care imparte tabela.
Nu critic (nu sunt in masura!) caut o solutie cat mai buna pentru evidenta de gestiune.
Cum sunt NIR si FAC, de ce n-ar fi bine ca fiecare document sa fie stocat in tabelele sale (doua, trei, cinci sau cate sunt nevoie pentru realizarea compromisului spatiu ocupat-viteza de executie) si replicate in TRANZACTII (care poate sa fie o tabela virtuala - in functie de server)?
Cu tabele separate pe fiecare document parca las mai mult loc pentru dezvoltari ulterioare.

*** Ce se intampla cu informatia perisabila din nomenclatoare (cataloage).
Inghetarea starii in varianta de listare a documentului e buna pentru rezolvarea litigiilor, nu vad cum as prelucra un PDF in alt scop.
E nevoie si de o altfel de solutie.
Am exemplu solutia SIVECO (folosita la SIUI) - fiecare tabela (gen catalog) are campurile: ValidFrom, ValidTo si cred ca un ID pentru a determina cine, cand si ce a modificat pe inregistrare.
ValidFrom si ValidTo sunt folosite de utilizator, nu fac parte din bucataria interna.
Am posibilitatea, ca utilizator, sa sterg fizic inregistrarea (log-ul noteaza) sau sa inchid perioada de valabilitate a inregistrarii (validTo). In felul acesta nu trebuie sa tin in alte tabele date redundante si am informatia corecta de la momentul X. Hm! La cat de repede merge sistemul am impresia ca era mai buna varianta cu replicarea informatiilor din cataloage pe doc. primare. (si aici trebuie aprofundat)

Multumesc oricui ajuta cu comentarii din experienta
 4/14/2011 10:53:12 AM
User is offlineDaniel Buduru
3522 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
@Dumitru

Tabela preturi contine preturile de vanzare, pe articol, punct de lucru, client, perioada de valabilitate.
Tabela cu preturi de intrare contine replicate intrarile / articol / gestiune si preturile pump, fifo, lifo.

In tranzactii sunt toate documentele interne, si toate au aceeasi structura. Sunt mai multe coloane decat cele pe  care le-am expus - cum ar fi in header id comanda, in detalii cantitate dispusa, astfel incat acomodeaza toate tipurile de documente interne.
Tabela de tranzactii, filtrata dupa articol / gestiune, este fisa de magazie - din acest motiv am ales solutia cu replicarea nirurilor si facturilor si inventarelor in aceasta tabela.
Eu folosesc acelasi form pentru toate documentele interne, se alege doar tipul documentului. In functie de tip, se afiseaza sau nu anumite elemente, se schimba etichete, astfel incat sa fie reprodus documntul care trebuie completat.
Modificarea structurii unui document le afecteaza pe toate, asa este, si este ceea ce am cautat. Este mai eficient ca toate documentele sa fie prelucrate cu acelasi algoritm, decat sa existe rutine particularizate pentru fiecare tabela.
Campurile cu acceasi functie au intodeauna acelasi nume. ID Document este acelasi lucru cu ID Nir, ID Factura, ID Bon, ID Aviz. Numar Document, Data Document sunt valabile si pentru Numar Bon, Numar Aviz, Numar NIR, Numar Factura... Cantitatea dispusa, cantitatea comandata sunt acelasi lucru, cantitatea eliberata si cantitatea iesita la fel. Nu e nevoie de structuri diferite pentru aceleasi informatii.
O solutie pentru particularizarea unui anume document, daca frecventa lui este mica si numarul de campuri suplimentare este mare, este asocierea unei tabele care contine informatia specifica, in relatie 1-to-1 cu tabela de tranzactii

Pe un server sql, modificarea structrurii unei tabele, crearea / modificarea indecsilor, a triggerelor si procedurilor se poate face din mers, in timp ce pe baza de date se lucreaza.

Toate nomenclatoarele au perioada de valabilitate a informatiei, doua campuri datetime, cu acceasi functie ValidFrom - ValidTo. La mine, fac parte din bucataria interna, istoricul se pastreaza in tabela, iar corelarea cu documentele se face si in functie de data. La modificarea unei inregistrari in nomenclatoare, daca modificarea este susceptibila sa schimbe intelesul datelor existente, data finala este completata cu data si ora curenta, si se creeaza o noua inregistrare cu data inceperii data si ora curenta.
O problema cu care m-am confruntat a fost schimbarea denumirii articolului la acelasi cod - nu o corectare a denumirii, ci cu totul alt produs. Daca nu ar fi existat logul de modificari, situatia ar fi fost grava. Acum denumirea articolului este una din informatiile care se afiseaza in functie de data documentului.

Pentru cazul in care un articol a fost codificat de mai multe ori, in mod eronat, exista o rutina care permite comasarea articolelor la unul singur.

In nomeclatorul de preturi, in care utilizatroul poate specifica cele doua date, daca sunt ulterioare datei curente.
Aceasta permite pregatirea unei modificari de pre inainte de momentul aplicarii ei. De ex, un pret poate fi modificat astazi, dar aplicabil doar peste doua zile,  sau un pret poate fi valabil un anumit interval, dupa care se revine la pretul anterior.

O parte din informatiile din nomenclatoare sunt doar referite in tabele, altele sunt copiate in tabele dupa selectia din lista. Trec in tabele acele informatii a caror modificare poate schimba valoarea inregistrarii. Nu e nici o diferenta - ca dimensiune a inregistrarii - intre a tine unitatea de masura tip caracter pe 4 octeti sau cod um integer pe 4, nici cota tva in procente.

In tabela de facturi header tin, intr-un camp memo, datele de identificare ale clientului - denumire completa, adresa, cod fiscal, asa cum erau cand s-a emis factura, iar in detalii, denumirea si codul articolului asa cum apare in factura

Pentru organizarea bazei de date trebuie stabilite mai intai interogarile si procesarile care se vor face pe aceasta baza de date.
Se face un model, se populeaza cu date, fie generate, fie - preferabil - dintr-o baza existenta, apoi se testeaza interogarile. Nu e necesar sa existe aplicatia, interogarile se pot face de la o consola sql - exista asa ceva pentru toate serverele, fie in standard, fie third-party.
Unele interogari pot fi prohibitive ca timp sau consum de resurse, iar in acest caz modelul trebuie ajustat.
Scindarea / unificarea tabelelor sunt destul de simple in sql, iar o baza de date poate fi duplicata la fel de simplu, astfel incat se pot face teste comparative pe diferite modele.

Daniel Buduru
 4/14/2011 7:30:24 PM
User is offlineDumitru
206 posts
4th


Re: unire tabele intrari si iesiri
 (N/A)
Wow! Multumesc pentru raspunsul amplu, m-a ajutat sa-mi lamuresc cateva probleme
E clar, trebuie inceput si revin unde am indoieli.
M-am gandit ca MySQL-ul este potrivit pentru mine, pot accesa baza atat intr-o retea locala cu aplicatii VFP, cat si pe net, unde MySQL e cel mai popular server, folosind o alta interfata (PHP, ASP sau JAVA).
Ceva-mi spune ca nu e bine, trebuie sa folosesc unelte de la acelasi producator ca se "pupa" bine si sunt dezvoltate concomitent. Ma mai gandesc si la .NET.


 4/14/2011 8:11:07 PM
User is offlineDaniel Buduru
3522 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
Eu lucrez cu sql server express 2008, care este free si pentru aplicatii comerciale. Este restrictionat insa la utilizarea pe server web.
Il utilizez si prin internet, cu acelasi client ca si in reteaua locala. Nu am avut nici un fel de probleme.
Aplicatia este stocata intr-o baza de date pe serverul sql. La client se distribuie doar un loader, carui i se indica adresa si portul serverului sql. Loaderul verifica daca exista local aplicatia la versiunea de pe server, daca nu exista sau nu e la versiune o descarca, apoi o lanseaza.
Daca serverul este in spatele unui router, e suficient un port forward pe serverul sql (preferabil alt port decat cel implicit).


Daniel Buduru
 4/15/2011 9:08:36 AM
User is offlineMihai ov
20 posts


Re: unire tabele intrari si iesiri
 (Romania)
D-n Daniel

Revin cu mai multe intrebari
Ati recreat clase din toate clasele de baza vfp sau ati folosit unele asa cum sunt
Pe partea de client creati pe local o tabela (sau mai multe) goala cu un select sql din server si folositi o tranzactie pentru un intreg documentul introdus in tabela respectiva
Daca e asa la update pe server cam ce fel de trigere folositi pentru verificare( in general ) folositi trigrere pe server sau incarcati datele separat in tabelele serverului din rutina clientului
Cat de mult detailiati clasele ( clase de navigere sau butoane ) sau ati scris un intreg form (one to many) pe care o instaniati repetat
Va recalculati formele in functie de rezolutia de ecran a clientului
Folositi vederi la distanta in partea de client
Asta e marele dezavantaj foxpro. Prea multe feluri in care poti face un lucru

cu stima
Mihai ov
 4/15/2011 12:04:40 PM
User is offlineDaniel Buduru
3522 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
 Mihai ov wrote
D-n Daniel

Revin cu mai multe intrebari
Ati recreat clase din toate clasele de baza vfp sau ati folosit unele asa cum sunt
Pe partea de client creati pe local o tabela (sau mai multe) goala cu un select sql din server si folositi o tranzactie pentru un intreg documentul introdus in tabela respectiva
Daca e asa la update pe server cam ce fel de trigere folositi pentru verificare( in general ) folositi trigrere pe server sau incarcati datele separat in tabelele serverului din rutina clientului
Cat de mult detailiati clasele ( clase de navigere sau butoane ) sau ati scris un intreg form (one to many) pe care o instaniati repetat
Va recalculati formele in functie de rezolutia de ecran a clientului
Folositi vederi la distanta in partea de client
Asta e marele dezavantaj foxpro. Prea multe feluri in care poti face un lucru

cu stima
Mihai ov


Mai folosesc clasele native doar cand postez un exemplu pe forum
In VFP exista un folder cu clase particularizate, utilizate in framework-ul vfp. Folderul se numeste FFC - Fox Foundation Classes.
Eu mi-am creat propriile clase, particularizate si cu o serie de proprietati si metode in plus - pe care le utilizez in framework-ul propriu.
Cand am nevoie de o clasa pentru un anume scop, o derivez din aceste clase.
Mi-a creat un framework, care contine obiecte specializate pentru anumite scopuri, obiecte create tot din clasele particularizate.
In framework exista obiecte care se ocupa de regasirea si salvarea datelor, obiecte pentru editarea datelor si altele pentru selectarea/ filtrarea lor.

Pentru examinarea, introducerea si actualizarea documentelor am creat o clasa derivata din container, in care sunt instantiate obiecte de genul celor pomenite mai sus. Desi e mai simlu de configurat o astfel de clasa daca este derivata din form, am preferat containerul, ceea ce imi permite sa instantiez mai multe astfel de obiecte in acelasi form.
Containerul contine controalele si un minim de metode, fiecare actiune insa este executata de un obiect specializat,

Navigarea cu butoane VCR este de mult depasita. Destul de dificil sa te misti din inregistrare in inregistrare pe cateva zeci - sute de mii de inregistari, nu?
Intr-o aplicatie client-server inseamna sa aduci de pe server toate inregistrarile tabelei, una cate una ...
Eu utilizez liste de selectie, filtrate, din care utilizatorul isi poate alege documentul/ inregistrarea pe care doreste sa il examineze / editeze.

SQLEXEC permite  executarea comenzilor sql pe server, intre care si select, update, insert. Doar ca trebuie scrise toate valorile in comanda sql, lucru nu tocmai la indemana in cazul tipului de date care nu se transforma simplu in caracter.

Utilizarea unui view actualizabil are avantajul ca el creeaza un cursor vfp, pe partea client, cu care se poate lucra ca si cu tabelele locale.
Unul din deazavantajele view-ului este acela ca se poate defini doar intr-o baza de date.
Alt dezavantaj este ca toate setarile se fac cu cursorsetprop.

CursorAdapter-ul creeaza un cursor definit de o comanda sql si  utilizeaza proprietati pentru setarea caracteristiclor cursorului, in loc de comenzi cursorsetprop.
CA genereaza automat comenzile sql insert, update, delete cu campurile si valorile necesare, dar exista si posibilitatea de a utiliza propriiile comenzi in locul celor generate automat.
In CA se poate face direct o conversie de tip, utilizand CursorSchema

View-ul si CA mai prezinta un avantaj, si anume acela ca refolosesc cursorul. Dupa fiecare requery, datele sunt aduse in acelasi cursor, astfel ca un grid nu-si pierde sursa la fiecare reimprospatare a datelor.

Utilizez CA pentru actualizari de date, ori de cate ori este necesar si posibil.

Pentru editarea/ salvarea datelor prefer sa lucrez cu intreg documentul odata, daca nu exista cerinta expresa de a salva fiecare linie dupa ce s-a terminat editarea ei.
"Intreg documentul" inseamna ca toate tabele din care este compus documentul si toate inregistrarile aferente documentului se actulizeaza in aceeasi tranzactie. Acest mod de lucru evita salvarea incompleta a documentului - daca o singura inregistrare este rejectata, nu se salveaza nimic din document.

Bussiness Rules se verifica pe partea de client, inainte de a salva documentul pe server.
Integritatea Referentiala este asigurata de server, pe baza constrangerilor definite in baza de date.
Triggerele nu sunt utilizate pentru verificare, ci pentru efectuarea altor operatii, cum ar fi replicarea unor informatii, crearea unor documente conexe, etc.

Toate formurile mele sunt scalabile. Daca dimensiunea initiala a formului este mai mare decat rezolutia ecranului, se redimensioneaza automat la instantiere astfel incat sa nu iasa in afara ecranului. Utilizatorul poate apoi sa-si redimensioneze formul dupa dorinta, dar exista si valorile minime width - height sub care nu se mai poate redimensiona.

In orice limbaj exista mai multe moduri in care poti face un anumit lucru. In vfp exista insa mai multe comenzi prin care se poate face acelasi lucru ...

Daniel Buduru
 4/15/2011 12:05:07 PM
User is offlineMihai ov
20 posts


Re: unire tabele intrari si iesiri
 (Romania)
D-n Daniel

Incarc o baza de date vfp de pornire fara mari pretentii
Am lucrat doar 3 ore pe ea
Acum , daca va puteti uita peste ea sa faceti cateva adnotari sau modificari ar fi de mare folos
Practic o sa folosesc metoda descrisa de dv mai sus , adica aceeasi structura pe tranzactii si tranzactii antet cu fisiere desprinse pt arhivele de documente mai mari (receptii si facturi)
Ulterior o sa fac upsizing pe expres sql 2008 deja instalat dat as vrea sa scriu trigere-le in vfp ( nu stiu daca merge) si trec scriu prima clasa de documete ( forma)

Puteti sa puneti si relatile + indexsi
Multumesc mult
 4/16/2011 10:44:43 AM
User is offlineDaniel Buduru
3522 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
Upsize la o baza de date vfp se justifica doar in cazul unei aplicatii existente.
Upsize Wizard nu proceseaza triggerele, ci doar realtiile d eintegritate referentiala.

A face baza de date in vfp si a o trece apoi pe sql server 2008 e cam acelasi lucru cu a face o aplicatie in fpd 2.o si a o compila in vfp9 ...
Serverul ofera mult mai multe posibilitati decat tabelele dbf si e neeconomic sa nu fie exploatate.
In acest caz, metoda pasilor extrem de mici nu va da rezultate.

Procedurile si functiile sql trebuie scrise in limbajul serverului - in cazul ms sql, limbajul este T-SQL.
Trebuie schimbata si abordarea, cod de genul m.variabila=tabela.camp nu este aplicabil in t-sql. Procedurile sql trebuie sa lucreze cu un set de inregistrari, nu doar cu o singura inregistrare.

Daniel Buduru
 4/17/2011 10:01:08 AM
User is offlineMihai ov
20 posts


Re: unire tabele intrari si iesiri
 (Romania)
Clientii mei din zona sunt firme mici cu computere p3 700 p4 1200 as vrea sa pastrez ambele baze de date. Cred ca asemenea resurse sunt prea mici pt sql server 2008
As vrea sa pastrez ambele baze de date vfp si sql si sa diferentiez conectica in functie de activitate si automatizarile care le vor

In alta ordine de idei
As dori sa scriu o singura comanda select care sa-mi faca un inventar dintrun fisier de vanzari amanuntit ceva de genul Select disitinct id_articol la care sa adaug in canatitate suma tuturor cantitatilor gasite pe respectivul id + data de iesire si denumirea .

Am nevoie sa scriu prima forma one to many cu 2 griduri unul pe tabelul antet si unul pe tabelul dataliu
Inca nu am ajuns la cursor adaptor daca aveti ceva idei acum sunt la el

Dupa ce ati creat clase dv. din clasele de baza in proiect ati inclus gridul intrun container sau il instantiati direct in form
Ati incus nomencatorul ca lista ascunsa in grid sau folositi un grid separat pe nomenclatorul de articole?
Pot fi adaugate clasele scrise la framework ulterior

Multumesc
Mihai ov
 4/17/2011 3:24:37 PM
User is offlineDumitru
206 posts
4th


Re: unire tabele intrari si iesiri
 (N/A) Modified By Dumitru  on 4/17/2011 3:32:59 PM)
 Mihai ov wrote Ati incus nomencatorul ca lista ascunsa in grid sau folositi un grid separat pe nomenclatorul de articole?

Pot sa-ti spun cum am rezolvat eu problema nomenclatoarelor, pana acum sunt multumit de cum functioneaza si cat de repede pot sa fac modificari in aplicatie.
Pentru fiecare nomenclator am creeat un obiect care este si vizual si nonvizual in functie de situatie.
In principal este un form modal care primeste parametru un obiect (custom) pe care-l si intoarce dar populat cu datele din inregistrarea selectata.

Daca gaseste inregistrarea dupa cheia care se gaseste in obiectul parametru, form-ul nu se instantiaza, se populeaza obiectul cu datele din inregistrare.
Daca nu o gaseste, se activeaza formul in care utilizatorul poate cauta, adauga, modifica, sterge si selecta articole (poate sa si abandoneze operatia).
In felul asta am creeat o singura data form-ul si-l folosesc peste tot unde am intr-o macheta a unui document de validat cu nomenclatorul valoarea din camp.

Utilizatorul introduce cateva caractere in camp, validarea consta in apelul form-ului nomenclator si dupa primirea raspunsului se inscrie in camp valorea corecta (eventual si in alte campuri - depinde de document).
Nu deranjeaza ca form-ul este modal doar validez un camp si nu-l las sa plece pana nu introduce corect.
Formu-ul are de fapt doi parametrii, al 2-lea este un flag care indica butoanele enabled (uneori nu are voie sa stearga de exemplu)

Am trecut cateva pe MySQL, a trebuit sa refac doar form-ul nomenclator si aplicatia functioneaza cu documente locale si nomenclatoare pe server. Acum ma gandesc cum sa trec si restul.
Oricum trebuie rescrise de aceea ma intersa subiectul cu structurarea bazei de date pentru evidenta de gestiune.
Nu fac prelucrari care implica folosirea nomenclatoarelor, la momentul introducerii retin tot din nomenclator pe document, este risipa dar tine loc si de log si inghetarea starii ma ajuta sa refac repede oricand un document, prelucrarile sunt simple (am toate datele fara a avea nevoie de JOIN) si ma scapa si de "certuri" cu utilizatorii. Are si dezavantaje, pe langa cel de spatiu ocupat, de aceea ma interea undeva mai sus chestiunea cu ValidFrom, ValidTo.
Am inteles de la Daniel cum sta treaba cu compromisul, date redundante-date relationate si nu indraznesc sa renunt la metoda asta pentru ca nu mi-am facut inca o baza logica pe care sa ma bazez in structurarea aplicatiei.
Orice critica ma ajuta si e bine primita.
Sper sa-i fie de ajutor si lui Mihai
 4/17/2011 10:10:33 PM
User is offlineMihai ov
20 posts


Re: unire tabele intrari si iesiri
 (Romania)
Metoda care o folosesti o folosesc si eu cam in acelasi mod acum
daca utilizatorul trece de un anumit camp din forma de culegere fara sa introduca denumirea deschid un form unde poate alege ce vrea
daca introduce o parte din denumire fac un select pe cuvintele cheie din denumire daca introduce doua cuvintecheie (fac select pe ambele cuvinte ex ( ampi 250 ) va gasi ampicilina 250 toti producatorii )
ca tot suntem pe farma. Formurile le setez cu variabile nu trebuie sa introduc decat denumirea formei tabelul variabila de cautare si gata.
Acum, eu am creat obiecte din toate clasele de baza si vreau sa lucrez cu clasa "cursor adapter" si "data envioronment adica CA DE mai pe scurt" la sugestia dn Daniel care parerea mea e foarte avansat . Pana acum am reusit sa-mi creez o clasa DE care contine Cursor adapter legat de sql printrun string de legatura cand apelez OpenTables() primesc datele selectate din server direct in cursoarele din clasa DE . Avantajul e ca pot creea un DE din cate tabele vrei de unde vrei si si din cate drivere de baze de date vrei inculusiv xml in acelasi timp.Deasemenea CA se ocupa si cu compatibilizarea datelor. Clasa fuctioneaza cu browse dar m-am blocat la popularea gridului. In optiuni am setat field maping asfel cad trag un cursor din DE imi creeaza un grid populat cu clasele mele care pot sa-l tranfer in orice forma vreau .Daca ai ceva idei aici imi sunt da ajutor

Cum procedez eu la proiectarea bazei

Cel mai important zic eu , principalele tabele trebuie sa se bazeze pe o structura identica in primele campuri asfel manipularea datelor devine mult mult mai usoara
Cel mai important tabel e tranzactii care dicteaza forma din restul tabelelor de arhivare a documentelor
Toate tabelele sunt parinte copil adica antet si detali .Tranzactii_antet si Tranzactii legate RI (integritate refrerentiala) prin primul camp deocamdata . Eu vad structura la tranzactii cam asa
Tabela tranzactii
id , data ,id_document,tip_doc, nr_doc , data_documentului ,id_articol,id_codbare,id_codmed,intrare , iesire, sold , pretunitar, id_tva , tva , gesitune_in , gestiune_out , cont_debit , cont_credit
Pentru receptii si facturi care sant documente mai uzate deci si inregistrari mai mari tabele separate derivate din tabela de mai jos cu trigere pt replicarea datelor in tranzacti

Tabela receptii
id , data ,id_document,tip_doc, nr_doc , data_documentului ,id_articol,id_codbare,id_codmed,intrare , iesire, sold , pretunitar, id_tva , tva , gesitune_in , gestiune_out , cont_debit , cont_credit + adaos_procent , adaos_valoare, discount,pret_final, tvaded, si altele

Trigerul din sql copiaza prima parte a tabelei in tranzactii, campurile sunt identice de acolo obtin situatii > fisa magazie >stoc etc
Nu uita de fisierul inventar de pornire (esti raspunzator de datele clientului de la inventar)
Nu se pot sterge documente sunt deacord cu dn. Daniel doar ultima inregistrare restul stornari (asa lucrez si acum)
Un triger de verificare pe id_articol intrari iesiri sold de la ultimul inventar zic ca rezolva o multime de probleme
Mai am fisiere pentru tip_tva tip_document preturi !! ,gestiuni . trebuie sa sti cateva moduri de descarare a gestiuni fifo ..... si multe altele care nu tin strict de gestiune
Acum daca ai idei le astep
O sa postez o baza dupa ce reusesc o inregistrare complecta receptie > stoc > facturare cu trigeri cu tot si cu o forma simpla
Daca ne uitam pe piata formele cam conti doua griduri
Mai vezi postu lui Dn Daniel pe la pagina 4

Cu stima Mihai
 4/17/2011 11:10:12 PM
User is offlineDumitru
206 posts
4th


Re: unire tabele intrari si iesiri
 (N/A)
Multumesc, e util schimbul de informatii.
Esti mai avansat, idei am dar daca nu le-am implementat nu au nici o valoare.
Luam aminte la Daniel, stie bine, e si parerea mea.

 7/2/2011 8:16:28 AM
User is offlineMihai ov
20 posts


Re: unire tabele intrari si iesiri
 (Romania)
Ce mai faceti dn. Buduru
A trecut cam mult timp de cand am postat dar am avut mult de lucru la chesti fara importanta .
Acum cand incerc sa reiau chestiunile mai vechi as dori sa va intreb, ce folositi de obicei pentru editare dupa ce aduceti datele din sql , un cursor sau un view care ar fi mai potrivit.
 7/2/2011 12:05:13 PM
User is offlineDaniel Buduru
3522 posts
1st




Re: unire tabele intrari si iesiri
 (N/A)
View-ul, fie local, fie remote, necesita o baza de date dbc pentru pastrarea definitiei view-ului, ceea ce complica lucrurile.

CurorAdapter (CA) este un obiect, deci poate fi configurat prin proprietati, fata de view sau sqlexec, care necesita cod. Desigur, se pot face clase care sa utilizeze view sau sqlexec pentru aducerea datelor, realizand astfel un cursoradapter propriu.
CA permite atat modificarea tipului/dimensiunii campurilor returnate - prin cursorschema - cat si utilizarea pripriului cod pentru delete, insert update.

Referitor la deschiderea tabelelor / view-urilor / cursoradapter: aici s-a dicutat de mai multe ori despre utilitatea sau inutilitatea deschiderii lor in Dataenvironment, si de fiecare data s-a omis o precizare.
Cei care nu mai folosesc dataenvironment nu deschid cursoarele in cod, in form.load sau form.init, asa cum s-a inteles de multe ori, ci si-au facut propiul datalayer.
Deschiderea tabelelor / cursoarelor in codul aplicatiei nu este abordare OOP, ci reminiscenta a programarii procedurale.


Daniel Buduru
  Visual FoxPro  Baze de date, tabele, view-uri si indecsi  unire tabele in...

Search  Forum Home         

 Google Ads Minimize

    

Copyright 2002-2013 Profox   Terms Of Use  Privacy Statement