Incerc, nu pot sa justific perfect tehnic - cred ca numai echipa VFP poate :)

Daca ne gindim ca VFP-ul cind ceri ceva dintr-o tabela trebuie sa citeasca si mai ales sa gaseasca informatiile, si ca nu exista nimic in serverul de fisiere care sa-i dea doar ce vrea el (gen SQL server) atunci masina client trebuie sa citeasca atita informatie cit e nevoie ca sa produca cererea ta.

Un 'browse for' este la fel de prost ca si un 'set filter' adica lent pentru ca in general trebuie sa parcurga intreaga tabela ca sa vada care inregistrari corespund - si uite asa vine ~ toata tabela din server, sau cel putin coloana respectiva prin citire pozitionata. Asta daca nu ai un index care sa optimizeze expresia din filtru pentru ca zic ei:

'If the current table is indexed on a field or fields specified in lExpression, Rushmore Query Optimization technology can optimize queries based on the field or fields.'

Parcurgerea unui index se face pe pagini BTree, structura arborescenta si stie unde sa sara in fisier sa citeasca urmatoarea informatie de care sigur are nevoie => nu citeste din retea portiuni inutile de fisier. Ulterior se duce in tabela dbf pozitionat si citeste exact inregistrarea de care are nevoie.

Incearca sa faci in loc de 'browse for' urmatoarea secventa: 
SET ORDER TO unindex
SET KEY TO 'blabla'   && presupunind ca filtrul vrei sa-l faci pe un cimp care este indexat
BROW

sa vezi atunci viteza.

Ce am zis mai sus este valabil si pentru fraze SQL pentru join si where.

Sa fiu daca mai pricep. Am facut testul cu aceeasi tabela din HDD local si tot nu foloseste optimizare. Si la browse si la select se micsoreaza timpii dar numai din cauza ca citeste din HDD local cu o viteza mult mai mare decit din retea.

Nu prea folosesc comparatii cu stringuri de lungime inegala in general in toate aplicatiile. Cimpul rezultat este de 5 chr.

Am dat un SYS(3054,12) ca sa vad ce zice de optimizare:
- la Select * from tabela where rezultat='SALNT' -> optimizare: none    valabil si local si din retea; valoarea exista si nrrec= ~60000
- la Select * from tabela where rezultat='SALIN' -> optimizare: none    valabil si local si din retea; valoarea nu exista

- la Select * from tabela where data={01/05/2005} -> optimizare: full     valabil si local si din retea; nrrec=~60000

Cum am index si pe 'rezultat' si pe 'data' de ce nu foloseste in primul caz? Am testat si cu SET ANSI On si Off