1) Nu lucrez cu baze anuale; Am tabela de iesiri-pozitii de 2104500 inregistrari si de 1254000K; urmatoarea este iesiri de 287000 inregistrari ; tot MDF-ul este 1,7Gb (de aia am si trecut pe Express pentru ca se tot marea si trebuia sa dau shrink)

2) La stoc (si la alte informatii) am triggere pe Ins, Upd, Del in tabelele de intrarip si iesirip pentru actualizare si in alte locuri pentru verificare reguli de business

3) Folosesc view-uri parametrizate pentru ecranele de introduceri de date si SQLEXEC pentru partile de raportare. La view am avantajul ca pot (si am folosit) 'field rule' pentru generare id inregistrare noua, verificari, ... CA este un pic mai complicat si nu am vazut avantajul folosirii lui. View-urile sint facute pe o conexiune dar care nu este folosita in timpul rularii pentru ca deschid view-ul cu USE view IN 0 CONNSTRING oapp.Connhandle unde oapp.Connhandle tine numarul dat de deschiderea conexiunii la pornirea aplicatiei.

1.Lucrez cu baze de date curente si istorice nu neaparat anuale.

Baza de date curenta poate sa contina   miscari  pe mai multe luni in lucru . Dupa inchiderea lunilor datele ajung in tabelele de istorice.

Ele pot fi prelucrate UNION cu cele curente pe orice perioda.

2.Exista doua feluri de calcul stocuri .

a. in timpul operarii iesirilor la nivel de pozitie cu ajutorul unor proceduri stocate pe serverul SQL care stiu sa determine rapid stocul pentru orice moment zi/ora cu metoda FIFO

b.trigere pe server care determina stocul general onLine la fiecare miscare 

3. Folosesc numai SQL Pass Through

imi place sa stiu ce se intampla pe server .Toate operatiile  le imbrac in tranzactii (reale sql) pe server prin SPT .

De exemplu la o factura trebuie sa fac o multime de lucruri in mai multe tabele : salvez pozitiile de miscari , sterg notele contabile vechi ,creez notele contable noi , alte statistici , loguri etc si asta poti sa faci ca lume numai prin SPT.

Se pierde mult timp pana scrii clasele necesare dar merita.

Probabil cursor adapterul ar asigura o viteza crescuta la dezvoltare insa nu pot controla tot traficul pe server .

Cristian Birlea - CLASSOFT

www.classoft.ro

Metoda de deschidere view este descrisa in help la USE.

Este mai putin reala o tranzactie in SQL Server prin metoda : (am scos partile de tratare a erorilor dintre linii ca sa fie mai clar) ?

SQLSETPROP(oapp.connhandle,"Transactions",2)
begin transaction
lerror=!tableupdate(.T.,.F.,ldatamaster)
lerror=!tableupdate(.T.,.F.,ldataslave)
if !lerror
   SQLCOMMIT(oapp.connhandle)
   end transaction
else
   SQLROLLBACK(oapp.connhandle)
   rollback
endif
SQLSETPROP(oapp.connhandle,"Transactions",1)

begin transaction / end transaction este important pentru VFP pentru ca nu are de unde sa stie ca pe server a dat eroare tableupdate si trebuie aduse la loc starile cimpurilor din view.

Prima instructiune SQLSETPROP deschide o tranzactie pe server incepind cu urmatoarea instructiune tableupdate si SQLCOMMIT inchide tranzactia. Este diferit efectul fata de SQLEXEC ? . Daca nu ma insel in SQLEXEC trebuie sa pui concatenat toate instructiunile dintre inceputul si sfirsitul tranzactiei altfel tranzactia se inchide la terminarea unui SQLEXEC.
Nu am avut nici o pierdere de integritate a datelor cu metoda view + procedura de mai sus.