Newsgroup: it.comp.lang.visual-basic
Titolo: AdoDB.connection - strategie

Nei miei programmi di solito creo un oggetto adoDB.connection pubblico, apro
la connessione all'avvio del programma e lo chiudo all'uscita del programma,
poi tutti i recordset usano come activeconnection tale oggetto. Tali
programmi accedono a un unico DB access e sono usati contemporaneamente in
media da 4 utenti.
Leggendo un libro sulla conversione da VB6 a 
VB.NET
 viene spiegato che per
ottimizzare le prestazioni e' bene aprire il piu' tardi possibile la
connessione e chiuderla il prima possibile.
Esattamente il contrario di quello che faccio!
Che ne pensate? E' corretto il suggerimento del libro? Devo quindi
continuare ad usare un oggetto pubblico che apro ad ogni recordset e chiudo
alla fine dell'uso del recordset?????
Grazie
Andrea

 connessione e chiuderla il prima possibile.
[CUT]
secondo me la soluzione ottima è un compromesso tra queste due.
io ad esempio apro/chiudo una connessione per ogni form ...
CIAO

alla fine dell'uso del recordset?????
Ti parlo per esperienza personale su un caso unico, quindi non ne ho la
certezza....
cmq. Ho realizzato un gestionale in cui utilizzavo il tuo metodo e avevo sempre
aperti circa una ventina di recordset (da circa 10000 record!)
Il nuovo programma che ho realizzato sfrutta invece il secondo metodo, apri,
chiudi, apri chiudi! Ti assicuro che le prestazioni sono veramente superiori!
Avendo un elevato numero di record, nel primo caso, a zonzo nell'applicazione
rallentava tutto! Soprattutto al momento dei salvataggi! Cosi' invece si fila
via che e' un piacere, in quanto rallenta un filino al momento del recordset
(impercettibile!) ma al momento del salvataggio la differenza e' davvero molta
(4-5 secondi su un K6-III)
Ciao
Fabio C.

 ha scritto nel messaggio
news:3d174a10...@news.fastwebnet.it...

Ciao a tutti
a riguardo delle connessioni 'volanti' permettetemi di dire
la mia:
le connessioni volanti sono consigliate in ambienti che richiedono
la gestione di recordset disconnessi (
VB.NET
 lo consiglia
in quanto quest'ultimo ambiente è progettato principalmente
per Internet, con il conseguente uso ed abuso dell'XML)
In ambienti statici come il vecchio (si fa per dire) VB 6 la creazione
e distruzione continua di connessioni non è consigliata, specie
in un ambiente puro Client-Server. Appesantisce inutilmente
il lavoro della rete. In più creare e settare diverse connessioni
invece che una sola indubbiamente richiede una maggiore stesura
e manutenzione del codice (devi inoltre ricordarti sempre di distruggere
gli oggetti, e non ti fidare del fatto che VB alla chiusura
dell'applicazione
distrugge tutti gli oggetti del processo; esperienza personale......)
Per concludere, se devi stendere un'applicazione solo per
un ambiente Client-Server, o addirittura totalmente locale,
il mio consiglio è di utilizzare meno connessioni possibili.
Cordiali saluti
Yoda
VB 6 BCP
(Balasso Certified Professional)

 alla fine dell'uso del recordset?????
Apro i database su oggetti globali all'inizio del programma e li chiudo solo
al suo abbandono.
All'inizio di ogni form apro solo i recordset che servono e li chiudo alla
chiusura del form.

 media da 4 utenti.
anche io creo una connessione unica, e avrei un ulteriore domanda:
(mi spiego meglio favendo un esempio) per aprire il dettagli di un cliente,
una volta selezionato, utilizzo una dll che mi fa aprire una form con tutti
i dati, per fare questo nella dll esiste una variabili alla quale va passato
il valore della connessione pubblica creata nella form principale come
dicevamo;
- questo provoca un rallentamento, un impegno maggiore della rete,
diminuisce le prestazione in presenza di + utenti ?
- c'è una strada migliore (fermo restando l'utilizzo di dll) ?
- lo stesso meccanismo lo utilizzo per ocx, c'è una strada migliore ?
grazie a tutti.



 Che ne pensate? E' corretto il suggerimento del libro?
Ha ragione il libro... :-)
ADODB sfrutta, se possibile, il pooling delle connessioni. Il che significa
che, qndo invochi il metodo Close() della tua istanza di ADODB.Connection,
in realtà la connessione rimane ancora aperta, anche se il tuo oggetto
Connection risulta chiuso. La Connection viene qndi "girata" alla successiva
istanza di ADODB.Connection che invoca il metodo Open(), per la quale
l'apertura della connessione è quindi solo "logica", e non fisica.
L'idea di base è che, in presenza di moltissime aperture/chiusure (caso
tipico: applicazioni web o cmq distribuite) il numero di utenti gestiti è,
in un dato istante, tipicamente inferiore a qllo delle connessioni realmente
aperte verso il db, alleggerendo il carico del DBMS. Il connection pooling,
inoltre, è disponibile sia utilizzando OLE DB sia utilizzando ODBC.
Trovi cmq una documentazione migliore su MSDN.
A.
UGIdotNET - 
http://www.ugidotnet.org

 UGIdotNET - 
http://www.ugidotnet.org
Salve di nuovo
mi dispiace dover contraddire qcn che si firma da
parte dell'UGIdotNET, gruppo che stimo molto,
ma non sono d'accordo con lui.
A monte della richiesta di Andrea mi sembra che ci
sia un ambiente distribuito molto limitato (Access, media 4 utenti
connessi alla volta, ...). Non è un ambiente per una grossa applicazione
distribuita, ne tantomeno un qualcosa che deve essere accessibile da
Internet. Stiamo parlando di un'applicazione che molto probabilmente
deve supportare un'azienda medio/piccola (basta guardare che la
base dati è Access e non , per esempio, SQL Server o Oracle).
Quando 'Mamma MS' ha cominciato ad implementare ADO in
mente aveva principalmente SQL Server, o comunque grossi
ambienti distribuiti. Ha reso compatibile ADO con altre basi dati
solo per la politica di 'portare quanta + acqua possibile al
proprio mulino....'. ADO gestisce bene il Pooling delle connessioni
quando è in sintonia con R-DBMS come SQL Server o Oracle,
in casi estremi anche con MainFrame AS 400, ma non rende,
ne dal punto di vista dell'efficienza, ne dal punto di vista della
gestione di connessioni 'Volanti', su DB non Service come Access.
Un DB di Access non è un Service, è semplicemente un file.
In questi casi è meglio utilizzare quante meno connessioni
possibili.
E questo lo dico solo per esperienza personale, avendo sviluppato
gestionali che dovevano poter operare dualmente sia su SQL Server
che su Access.
L'MSDN non dice quello che serve ad un analista; dice quello
che 'Mamma MS' vuole per la diffusione delle sue tecnologie.
Personalmente è da utilizzare solo come un riferimento tecnico,
e non analitico.
Spero di non aver urtato nessuno con questa mia risposta
che non potevo non dare.
I miei rispettosi saluti



[cut]
mi associo al 100%
(e non vedo come si possa dissentire)
ciao
ugo

 ha scritto nel messaggio
news:rIHR8.31$Jj7....@news1.tin.it...
ZACCHETE!
Allora il libro ha ragione e poi tutti voglion dire la sua!
...e allora anche io dico la mia!
Se hai un progetto che usa ACCess monoutente allora usa DAO!...vedi post mio
di oggi in risposta a fabio qui sopra.
Quindi siamo nella ipotesi che usi ADO perchè ti serve e non perchè sei
"alla moda".
Con queste premesse...
 anche io intuitivamente fino a poco tempo fa dicevo...
"apro la conn...alloco memoria e risorse...se poi la chiudo e
riapro...ammazza che spreco di risorse....la tengo aperta dall'inizio alla
fine...."
poi ...qualcuno mi illuminò (credo sia stato Hal!)...e approfondii..e
scoprii (ammazza che italiano) che sbagliavo...il senso comune sbagliava.
c'è il meccanismo del "connection pooling" di default attivo su tutti gli
OLEDB e attivabile da pannello di controllo anche sulla conn ODBC ("pool di
connessioni")...tramite sta tecnica...ADO ricicla le connessioni allocate ma
non attive e le ri usa (non spreca memoria ...limitatissime risorse)....Ecco
perchè ti dicono di aprire e chiudere quando non serve più! per rendere
disponibile la tua conn (ex-conn) a qualcun'altro!
Inoltre su una conn aperta dall'inizio alla fine della sessione del tuo
utente non hai un controllo molto stringente su essa.
il conn.state=adstateOpen non è molto affidabile! Se si rompe un HD sul db
remoto la sente ancora attiva!...solo per questo sarebbe opportuno aprirla e
chiuderla solo per il tempo necessario...
Poi la fatica ed il tedio ci fanno fare ipotesi di compromesso....aprila
all'apertura del form e chiudila alla chiusura ...ad esempio....
ma ci si potrebbe fare anche una classe o una serie di funzioni che aprono,
eseguono, caricano il recordset e chiudono la conn....si dura fatica una
sola volta e si usano funzioni o classi per manipolare il recordset....
in NET poi.....
http://www.devleap.it/Document.aspx?IdDoc=694
cmq in internet trovi molta roba sul "connection pooling"
es.
Attivazione del connection pooling dell' ODBC via ADO
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q237844
solo per il titolo.. "A dip in the pool " eh eh! :-D
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvbdev00/h
tml/Rob.asp?frame=true
etc. etc.!
P.S.
Certo si parla di client server, di programmi in rete, etc
etc....ripeto....mono utente: ACCESS+DAO....ciauz!


