Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Ado.net: ma non ci sono più i cursori?

Ma non ci sono più i cursori e altre opzioni varie per tentare di 
migliorare le prestazioni di 
ado.net
?
In seguito ai miei post dei giorni scorsi ho scoperto che
1) buona parte del tempo perso per la DataAdapter.Fill era dovuta al 
fatto che se la connection era chiusa questa la apriva automaticamente e 
la open della connection occupava parecchio tempo.
2) Se uso un DataReader anzichè un DataAdapter la differenza di tempo è 
decisiva (il datareader è quasi immediata, il dataadapter.fill continua 
ad essere parecchio lungo)
Quindi pensavo di giocare un po' su opzioni varie degli oggetti vari per 
avere una buona velocità e la possibilità di aggiornare i dati.
Qualcuno ne sa qualcosa?
Ciao, grazie

 ad essere parecchio lungo)
Con il DataReader 
ADO.NET
 è in modalità connessa,
quindi è più velore,
ma la connessione va gestita a manina,
aprire e finito, chiuderla subito.
Per evitare di dimenticarlo aggiungo
un Finally alla gestione degli errori, e lì chiudo.
Anche se non è aperta e si utilizza il close, non presenta problemi;
invece una connessione non utilizzata aperta, incide sulle prestazioni.
Il DataAdapter, per me, è una soluzione stupenda, diciamo che rallenta un
pochino;
neccessita verificare in quale situazione deve essere utilizzata, quanto
tempo in più incide rispetto all'utilizzo , ecc.
Consideriamo che è la classe a gestire l'apertura e la chiusura, a fine
operazione, della connessione.
Ave
giuseppeD

 pochino;
Pochino???
Sul PocketPC ci mette 2 minuti per caricarmi 2000 record!
Non č possibile almeno paginare o settare qualche opzione in modo che i 
due minuti mi diventino non piů di 10 secondi?
Ciao, grazie

Ma non si puň fare il Fill di un dataset con un datareader?
Se mi devo compilare il il dataset č ancora piů veloce il dataadapter :(
Ciao

 due minuti mi diventino non pių di 10 secondi?
La paginazione in 
ADO.NET
 č semplificata rispetto ad ADO .
Utilizzato ad oggi due metodi:
1-
Overloads Public Function Fill(DataSet, Integer, Integer, String) As Integer
2-
Costruito l'istruzione SQL con String.Format
 Overloads Public Shared Function Format(String, Object, Object) As String
Carichi il numero di record desiderato a click. (esperienza sempre su pc)
Ave
giuseppeD

 Se mi devo compilare il il dataset è ancora più veloce il dataadapter :(
Ritengo che 
ADO.NET
 ha delle potenzialità molto superiori rispetto ad ADO.
Per non parlare dell'accoppiata con XML
Ave
giuseppeD

  Overloads Public Shared Function Format(String, Object, Object) As String
Questa non l'ho capita, in che modo la useresti?
Ciao
--
Math Parser : 
http://www.neodatatype.net
Sito Comune : 
http://www.it-lang-vb.net

 Questa non l'ho capita, in che modo la useresti?
Per pagine
Ave
giuseppeD

 Per pagine
Continuo a non capire cosa c'entri con l'interrogazione al db :)
Ciao

 Continuo a non capire cosa c'entri con l'interrogazione al db :)
Momento,
risposta successiva.
Ave
giuseppeD

 Non č possibile almeno paginare
Quindi paginare.
Quindi caricare e visualizzare solo una parte dei record.
La prima proposta mi sembra di utilizzo immediato.
La seconda permette di lavorare per pagine, visualizzare lo scorrere delle
pagina, spostarsi alla pagina desiderata e visualizzare i record di quella
pagina.
Con la prima soluzione ho realizzato Prima pagina ; pagina indietro ; pagina
avanti ; ultima pagina.
Tra la prima e l'ultima č uno scorrimento step dopo step.
La seconda soluzione, oltre allo step dopo step, prima e ultima pagina,
permette di posizionarmi immediatamente es. alla pagina 10, saltare alla
pagina 3, e cosě di seguito.
All'inizio necessita calcolare il numero di pagine in base ai record per
pagina che si vogliono visualizzare,
quidi memorizzare in variabili i vari parametri.
Ave
giuseppeD

 spariscono dopo la lettura.
In effetti il datareader è una lippa, ma non ho trovato un modo per ottenere
un Dataset o una DataTable o qualcosa da agganciabile a una DBGrid.
Comunque ho notato che il tempo utilizzato per fare la Fill cresce
esponenzialmente a crescere del numero di campi estrapolati dalla select,
quindi alla fine credo proprio sia una questione di prestazioni hardware
(oppure il CompactFramework non è molto ottimizzato :) ).
