Newsgroup: it.comp.lang.visual-basic
Titolo: [?]un chiarimento su Connessione ADO

io torno alla carica su un argomento che mi sta a cuore.
leggendo un libro sulle ASP...quello di Carlo Pelliccia "asp guida
definitiva"
trovo un piccolo trafiletto che, se ha un senso per quanto riguarda le asp,
mi ha posto un po di problemi per il vb
cito:
"
....La situazione non migliora fornendo lo scope "session" (ad una
connection): in questo caso molte connessioni rimarrebbero a lungo attive,
stressando tanto il server quanto il database.
La cosa migliore è creare e distruggere connessioni in ogni pagina.
ADO, infatti, è stato ottimizzzato per questo scopo, attraverso il
meccanismo di connection pooling."
Quindi il mio dubbio è questo, estrapolando il trafiletto, in ambiente VB:
Ho sempre scazzato in tutti i miei prog ad avere una sola conn aperta
all'inizio dell'app e chiusa all'uscita.
E' meglio secondo Pelliccia aprire e chiudere connection a iosa per ogni
form e chiuderle all'uscita del form.
Vi risulta?
Saluti
:-)


Ciao io personalmente ho sempre cercato di mantenere il DB aperto e
sopratutto tavole aperte il meno possibile perche qua Panama esistono
problemi con le Reti eletriche e anche se tutti i miei PC usano UPS  ho
sempre avuto il temore che uno sbalzo di corente potesse causare un errore
nella base dato se in quel momento fosse aperta e peggio ancora se sto
cercando di registrare o modificare un campo/i  cosi sempre per curarmi la
salute utilizzo un sistema poco ortodosso che fino ad hora mi funziona  con
il programma del Ristorante praticamente e cosi quando un tavolo mi ordina
ricavo il piatto dalla BD aprendo Dynasets clonato di solo lettura schiaccio
il bottone corispondente al piatto carica il dati del piatto in un listBox e
al momento che lo mando alla stampante della cucina lo registro in un file
TXT quando incasso Cancello il TXT del Tavolo e scrivo i dati in file
Generalexx-xx-xx.TXT.
Alla mattina sicronizo la tavola del inventario cosi se sucede qualsiasi
cosa ho tempo di corregere il problema prima di incominciare a cucinare.
Questo el la mia esperienza e devo dire che fino adesso mi e andata bene
Ciao L'Oriundo.

Dipende dalle situazioni. Diciamo che non esiste una
regola fissa, almeno parlo per quello che ho potuto
capire e sperimentare fino ad oggi.
Ma per ribadisco il concetto situazioni -affrontato
anche parzialmente da  oridundo.
Esempio. Instabilità elettrica, niente ups, base dati
tipo access che non ha transazioni e tabelle di rollback
beh sarebbe caldo e consigliato un apri e chiudi.
Esempio 2. Rete peer to peer o con server ecc ecc.
Dove il traffico di rete è una cosa abominevole e tu
devi fare una query una ogni 15 minuti ... beh apri
e chiudi, inutile tenere in piedi una connessione con
relativi polling al db ... se sai che non la usi.
Discorso diverso invece è il recordset, che consumando
più memoria che mai, è bene aprire e chiudere sempre.
E al massimo, se proprio ti serve un recordset, utilizzare
il recordset disconnesso.
OT: Ecco perchè Microsoft con il nuovo ADO.Net ha
cassato i cursori lato server. Proprio per indurre i programmatori
ad una programmazione più corretta e meno dispendistica
in termini di risorse.
Il fatto che vb e ado siano estremamente semplici da utilizzare
non significa che il primo cursore che implementiamo e poi
copiato e incollato all'ennesima potenza nei progetti che
facciamo sia sempre quello corretto.
La cosa purtroppo è difficile da mandare giù - ecco perchè
nel prossimo futuro 
ado.net
 riavrà a fardello anche i cursori
lato server ... ma una meditatina all'acquisto di un buon
manuale ado sicuramente non sarebbe un cattivo investimento.
Ciao Andrea

 Vi risulta?
Sono d'accordo con Pelliccia, anche se dipende molto dalle situazioni
che devi gestire con i tuoi programmi.
Personalmente,  tengo in vita una connessione per il tempo
più breve che sia possibile, lavorando spesso con recordsets disconnessi,
questo ti mette al sicuro da cadute di tensione, pause caffè che si
prolungano nel tempo etc... saprai benissimo che una connessione
consuma risorse preziose, quindi cerco di non abusarne.
Considera che per la nuova piattaforma NET e più precisamente 
ADO.NET
questo sarà pressochè lo standard : connessioni, recupero dati,
disconnessione,
elaborazione dati, riconnessione, aggiornamento and so on....
Ciao
 Valter

 tipo access che non ha transazioni e tabelle di rollback
[CUT]
Scusa una curiosita quando dici che Access non ha transazioni e tabelle
rollback cosa vuoi dire che non registra gli errori di transazione o che non
sopporta il metodo rollback del ogetto Workspaces
Grazie
L'oriundo

 Dipende dalle situazioni. Diciamo che non esiste una
mmm...però usando il lato client...non stresso poi il db e sopratutto la
rete in aggiornamenti e sincronizzazioni continue?...figuriamoci...ho sempre
(se potuto) usato il lato server...anche perchè un conto è comprare UN solo
server potentissimo...altro 10 pc mediamente potenti....azz Intel e Cisco
sono in crisi e M$ li tira la volata eh??!!
saluti!

 consuma risorse preziose, quindi cerco di non abusarne.
CUT
beh l'idea è sempre stata che se il server è dimensionato una volta
stabilita la conn e testato che sia viva, il client ha molte meno esigenze e
"respira " un po di più.
Mi sa che dovrò rivedere un po tutto...cursori solo client in
ado.net?...l'execute
 ce lo lasciano oppure tolgono anche quello??? :-P
ciao e grazie!

Assolutamente no ... lato client ... lo dice la parola
stessa ... stressi il client ... ovvio che all'inizio il
recordset deve essere sparato in toto al client ...
ci sarà uno stress iniziale ... ma poi lavora tutto
il pc client ... e solo su operazioni di update rispedisci
i record cambiati (o anche tutti) al server che li aggiorna.
Access ovviamente non avrà una gran bella performance
se hai un db di grandi dimensioni ... ma con veri rdbms
la qualità la noti subito.
Ciao Andrea

Si, mi riferisco alla tabella di rollback dove vengono
memorizzate tutte le operazioni fatte sul db ... in
via permanente o in via transazionale.
Ciao Andrea


Ti faccio sapere appena ho finito di leggere i polpettoni che ho acquistato,
magari dopo l'11 Aprile, giorno della presentazione di 
VB.NET
 a Milano,
alla quale credo convenga non mancare, vista l'aria che tira....
Ciao
 Valter