Newsgroup: it.comp.lang.visual-basic
Titolo: Meglio usare i RECORDSET o SQL

Salve, sono un principiante di vb, vorrei chiedervi un parere:
secondo per sviluppare la gestione
(inserimento/variazione/eliminazione) di un'anagrafica clienti e' cosa
e' piu' adatto, aprire un recordset sulla tabella e poi usare i propri
metodi per eseguire inserimenti/variazioni/eliminazione dei record
oppure usare comandi SQL.
Altro dubbio, come faccio a sfruttare gli indici di una tabella quando
voglio ricercare un record dentro un recordset ? Usando i comandi SQL
l'uso degli indici dovrebbero essere gestiti in automatico o sbaglio ?
Scusate se ho fatto delle domande banali, ciao a tutti.


CIAO


mi spiego meglio, io anni fa programmavo con dbase IV e avevo a
disposizione il comando 
SEEK chiave 
che mi cercava un record corrispondente alla chiave fornita sfruttando
l'indice corrente
altrimenti avevo il comando 
FIND espressione
che mi trovava il primo record che soddisfaceva l'espressione data,
che pero' non usava l'indice e quindi piu' lento.
Ora mi chiedo, esiste un comando simile al seek (ovvero che sfrutti
gli indici per la ricerca) per un recordset ?
Con sql invece e' automatico l'utilizzo degli indici ? ovvero capisce
lui quando deve utilizzarli per eseguire la ricerca ?
Faccio un esempio, mettiamo che ho una tabella contenente
un'anagrafica clienti con un indice con chiave il campo codicefiscale
se io eseguo il comando 
SELECT * FROM tabella WHERE codicefiscale=chiave_di_ricerca
per la ricerca viene usato l'indice ??

 per la ricerca viene usato l'indice ??
Si, certo. Infatti è importante inserire degli indici nella struttura delle
tabelle che si usano, perché altrimenti funziona tutto ugualmente, ma i
tempi di risposta delle query sono biblici.
Ciao
*Roby*

 Si, o almeno si spera.
<g> :)


 mi sembrava che con 2.5 avessero rimesso il seek, almeno con access.
Se le cose stanno così, forse vale la pena di dare un'occhiata anche ad ADO.
;-)
Ciao e grazie
*Roby*

tempi di risposta delle query sono biblici.
Con questo hai risposto anche alla domanda che avevo fatto nel primo
post, ovvero meglio apreire un recordset su un'intera tabella e poi
fare ricerca/variazione/inserimento/eliminazione di record li dentro o
tutto tramite sql.
Se i recordset non gestiscono gli indici di conseguenza tutto si deve
spostare su sql.
Ti ringrazio tanto, ciao.

 spostare su sql.
Aspetta, io parlavo solo di query complesse su più tabelle.
Poniamo che tu faccia un:
SELECT TEST.Codice, TabellaPivot.Descrizione
FROM TEST
INNER JOIN TabellaPivot ON (TEST.Codice = TabellaPivot.Codice);
In questo caso, se anche tu avessi avuto un indice sulla TabellaPivot nel
campo Descrizione, te lo sei perso (ovvero esso non è più presente nel
risultato della query, che non è ordinata).
Però se tu fai:
Select TabellaPivot.Descrizione Order By TabellaPivot.Descrizione
Ti ritrovi un recordset ordinato che utilizza l'indice preesistente della
tua tabella TabellaPivot. Anche se fai una query che estrae un sottoinsieme
di record, e lo ordina con la Order By, il motore di database crea un indice
temporaneo che è poi ingrado di utilizzare nelle query successive, almeno
fino a che continua ad esistere la prima query.
Il problema è che se TabellaPivot ha due indici, uno su Codice e l'altro su
Descrizione, non puoi passare da uno all'altro senza riaprire la query,
mentre con l'uso delle vecchie Table si poteva.
Su query semplici non è un problema, mentre su query complesse rigenerare
una query solo per cambiare un indice, potrebbe far sprecare molto tempo.
Una volta (in DB3 per esempio) le query non esistevano ed erano sostituite
da sequenze di seek su più tabelle. In quel modo si faticava di più a
scrivere il codice, ma cambiare un indice al volo era questione di un
attimo.
E' più chiaro adesso?
Ciao
*Roby*
P.S.
Prendi sempre tutto con beneficio di inventario. Se vuoi essere certo della
velocità, fai delle semplici prove di timing.