Newsgroup: it.comp.lang.visual-basic
Titolo: Stored Procedure. Dove Metterle?

Salve a tutti,
Secondo la Vostra esperienza , utilizzando un database access, č meglio
creare le query con access e poi richiamarle dall'interno di un programma
sviluppato in vb oppure č meglio creare le query via codice?
Grazie a tutti
Marco

 Marco
Beh direi intanto che un doveroso chiarimento sul Subject và fatto.
Le SP non sono oggetti di Access(o meglio JET nel tuo caso).
JET ti mette a disposizione Queries.
Proprio per questo motivo, o meglio questa particolarità, essendo
il ResultSet elaborato in Locale non dovrebbe fare nessuna differenza.
Le queries compilate possono dare l'impressione
di essere più veloci, ma credo che accada solo con progetti Access-JET
che hanno la possibilità di lavorare con Tabelle Linkate al Server.
Nel tuo caso VB+JET l'ottimizzazione avviene solo e semplicemente
ottimizzando
l'uso degli Indici, ma l'estrazione del ResultSet è sempre in LOCALE.
Ciao
-- 
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.mantuanet.it/alessandro.baraldi/
---------------------------------------------------------------------------

 Marco
Beh, access non è propriamente il luogo più opportuno per parlare di
stored procedure.
Access infatti NON ha stored procedure ma solo query eventualmente con
parametri.
Se non sai che differenza c'è vuol dire che non hai mai visto una stored
procedure.
Rimanendo alle query con parametri personalmente ho sperimentato che le
query memorizzate sono più pulite rispetto a quelle scritte dinamicamente.
Prestazioni? non si possono fare generalizzazioni, una query da vb è molto
più flessibile mentre le query "residenti" sono migliori se richiamate più
volte e/o non hanno bisogno di essere costruite dinamicamente.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Marco ha scritto:

Se fosse "sempre" meglio una cosa rispetto ad un'altra, allora "l'altra" 
cosa non dovrebbe esistere, a favore della prima che sarebbe, appunto, 
"sempre" da preferire all'altra. Puoi, pero', esaminare le 
caratteristiche dell'una e dell'altra.
Ad esempio, una query inglobata nel DB č piu' veloce, perchč il codice 
non deve essere controllato ad ogni esecuzione.
In caso di modifiche al codice SQL, pero', devi modificare tutti i DB 
che ne fanno uso.


io preferisco crearle da codice perché alla fine l'applicazione è più 
portabile e perché così mi gestisco più facilmente le "varianti", che non 
sono necessariamente modifiche di parametri (peraltro antipatici da usare) 
ma anche -a volte- modifiche strutturali. Mi capita infatti di avere una 
form di ricerca con vari campi e, secondo quali campi vengono utilizzati, 
metto in JOIN tabelle supplementari. Forse così è un pò meno efficiente ma 
in realtà questo è vero se devi fare tantissime query e piccole, se invece 
devi farne poche o pesanti, l'overhead della "compilazione" della query 
diventa assolutamente trascurabile.
Consiglio di avere sempre una classe che espone tuttti i metodi necessari 
per accedere/modifcare i dati in modo da mantenere cmq separata la logica 
applicativa (cioè la generazione degli statement sql e delle transazioni, il 
cosiddetto Business Layer) dall'interfaccia utente (sia essa web o VB 
classica). Inoltre consiglio di avere una procedura (o classe) di 
interfaccia con il DB che gestisce gli errori in modo unificato e che ti 
permette facilemente, per esempio, di intercettare tutto ciò che arriva o 
proviene dal DB (il Data Layer).
Recentemente ho migrato un grosso applicativo (IIS Application basato su 
webclass), su cui avevo lavorato per anni, da Access a MSDE/SQL Server. 
Grazie a questa strutturazione ci ho messo non più di mezza giornata (e sono 
rimasto sorpreso di quanto MSDE fosse più veloce di Access).
Ciao
Elef