Newsgroup: it.comp.lang.visual-basic
Titolo: Esecuzione query sql "lato-server" ??

Ho realizzato un'applicazione in Visual Basic che si collega (ADO -
ODBC) ad un database posizionato su un server.
Le query vengono inviate al database, dall'applicazione client, come
semplici stringhe utilizzando il metodo 'execute'.
Anche se non me ne capisco moltissimo, mi sembra di aver capito che se
le query fossero memorizzate direttamente nel db i tempi di
restituzione dei recordset sarebbero piu' veloci in quanto sarebbe il
db stesso ad occuparsi della compilazione della query e non
l'applicazione VB.
E' vero ?
Se si, sareste cosi' gentili ad indicarmi in che maniera si realizza
una query di questo tipo ?
Grazie

 ha scritto nel messaggio
news:384f424a.01091...@posting.google.com...

Che DB usi  ? perchè hai bisogno di un provider ODBC con ADO ?
comunque ...
i recordset lato server e client differiscono solo per la locazione dei
cursori (e quindi anche il tipo di operazioni) e non per la possibilità di
compilare query sul server o sul client.
Le interrogazioni vengono sempre eseguite sul server (perchè è li che
risiedono le tabelle);
Quindi i casi sono 2 :
- lato client : prelevo dal server tutti i record, li trasferisco nel
client, elaboro i dati, ritrasmetto al server gli aggiornamenti se
necessario
- lato server : trasmetto al server una serie di istruzioni, il server
preleva i dati e restituisce solo i risultati richiesti dal cursore in uso
(questo spiega perchè non esistono cursori lato server di tipo statico)
Utilizzando delle query precompilate (come appunto le query parametriche di
Access o le Stored Procedures di SQL S7) si ha la possibilità di evitare la
fase di parsing delle stringhe SQL, facendo eseguire al reale motore del DB
le operazioni (quindi la velocità aumenta).
Sembrerebbe dunque che le query salvate nel DB possano essere utilizzate
solo con recordset lato Server; fortunatamente non è così in quanto la
proprietà CursorLocation, ripeto, stabilisce solo la posizione dei cursori e
non la posizione di esecuzione delle query.
Tuttavia, fino alla versione 2.5 di ADO, i recordset restituiti da una
Stored Procedure non sono aggiornabili, tanto vale dunque utilizzare cursori
lato server.
Il discorso sui cursori comunque è molto vasto e strettamente legato anche
dal tipo di motore e dal provider utilizzato.Comunque nei vecchi post
dovresti trovare intense discussioni in merito.
Saluti

 Saluti
Grazie per la tua consulenza

 ADO 2.6 ha risolto questa situazione ?
Non ho acora provato :(
Saluti

 registrata col DB :)
E una, invece, con diverse JOIN su piu' tabelle , qualche WHERE, GROUP
e SORT BY applicata su piu' tabelle (7/10) di un solo db ?
Che ne dici ?
Varrebbe la pena sbattersi per registrarla nel db ?
Come sempre ... grazie !
Ciao


Yes .. anzi è doveroso !
Pensa solo al tempo sprecato dal motore Jet per verificare cha la sintassi
SQL sia corretta e creare un metacodice di sua facile interpretazione e
questo ogni volta che lanci un'istruzione SQL da codice.
Ti ringrazio per i complimenti precedenti ma ti assicuro che la mia
conoscenza deriva solo dai manuali, da internet e soprattutto dal NG.
E poi qui c'è gente che ne sa molto più di me e che sa spiegarsi anche
meglio; ma ognuno ha i suoi limiti :)
Saluti

 meglio; ma ognuno ha i suoi limiti :)
Beh .... in tutta' sincerita' ... vorrei essere "limitato" come voi... !!!
:-)
Grazie ancora

 Grazie.
Esattamente cosa non riesci a fare ?
Saluti

 Esattamente cosa non riesci a fare ?
Vorrei fare quello che mi hai consigliato tu, e cioe' inserire la query
dentro al db e chiamarla dall'applicazione VB.
Sono capace ad inserire una query attraverso access ed eseguirla sempre da
access.
Solo che in questo modo tutte le varie clausole sono statiche.
Quello che non mi e' chiaro , e' come fare a "passare" tutti i parametri
della query dall'applicazione VB alla query memorizzata nel db.
Intanto provo a dare un'occhiata alla guida in linea.
A proposito ... uso Access 2000.
Ciao