Newsgroup: it.comp.lang.visual-basic
Titolo: tutorial ado.net

salve a tutti.
tempo fa avevo scritto delgi appunti durante lo studio di 
ado.net
.
Sono degli appunti presi studiando il libro "vb 2005 Databases - From
novice to professional". li avevo scritti in word ed ora ho deciso di
pubblicarli sul mio sito.
potete trovarli a questo indirizzo:
http://www.theeasyweb.net/index.php?option=com_content&view=category&id=41&Itemid=64
capisco che chi è esperto in questo campo non perderà tempo a leggersi
le mie guide da niubbo, ma mi piacerebbe tanto ricevere delle critiche
costruttive per migliorare il livello delle mie guide e, non per
ultimo, la mia conoscenza.
al momento manca ancora qualche paragrafo, come il databinding e cose
del genere..spero di poter pubblicare a breve anche quelli.

Arrivo da Delphi e mi sto cimentando in 
VB.NET
. I tuoi appunti sono brevi, 
semplici e puntuali e mi stanno chiarendo le idee sulla confusione fatta 
causa le molteplici (anche troppe per il mio gusto) soluzioni possibile per 
eseguire la stessa funzione.... lette per necessit� anche troppo in fretta.
Volevo segnalarti/chiederti questo: nella lezione 3, il datareader non viene 
chiuso, ma ho letto nella guida che si dovrebbe farlo:
dtrdr.Close()
E' una dimenticanza, oppure � implicito quando il reader arriva ... diciamo 
EOF dopo il ciclo, opppure � implicito alla chiusura della procedura (quindi 
al rilascio dell'oggetto)?
Ciao, Gianni

 Ciao, Gianni
ï¿œ una dimenticanza/leggerezza. quando la procedura termina anche il 
datareader viene cancellato come tutti gli altri oggetti ma una 
procedura *seria* dovrebbe sempre assicurarsi di fare le pulizie prima 
di chiudere :)
-- 
IgnazioC
My 3W Experiment: 
www.theeasyweb.net

dopo aver letto il paragrafo su update/insert/delete, ti suggerisco alcune 
precisazioni, che potresti magari inserire in un paragrafo 
"approfondimenti", tanto per non appesantire quello esistente. Ovviamente 
correggimi se dovessi scrivere delle cavolate.
1. prendiamo la definizione dei parametri dei tuoi esempi
      Dim upd As String = "update clienti set citt� =@citt� WHERE 
idcliente=@IDcliente"
.....
         cmd.Parameters.Add("@citt�", OleDbType.VarChar, 15, "citt�")
         cmd.Parameters.Add("@idcliente", OleDbType.VarChar, 5, "idcliente")
al principiante (come me), sembra che i parametri debbano essere definiti: 
@Nomecamporappresentatodalparametro.
In realt� non � cos�, ma vale :
      Dim upd As String = "update clienti set citt� =@param1 WHERE 
idcliente=@param2"
.....
         cmd.Parameters.Add("param1", OleDbType.VarChar, 15, "citt�")
         cmd.Parameters.Add("param2", OleDbType.VarChar, 5, "idcliente")
Cio� i nomi dei parametri sono liberi e nel "Add" non occorre scrivere la @ 
davanti: l'add serve proprio per legare il parametro al campo, altrimenti 
non servirebbe l'add poich� sarebbe tutto implicito (anche le info sul tipo 
e le dimensioni del campo l'adapter se le pu� ritrovare da solo, giusto?)
La cosa � irrilevante su comandi come quelli del tuo esempio, ma in altri 
casi si. Ad esempio, se dovessi modificare tutti i record con 
citt�="castelfranco" in "castelfranco veneto", cio�
"UPDATE clienti SET citt�=@citta WHERE citt�=@citta"
allora avrei bisogno di due parametri che fanno riferimento allo stesso 
campo, uno con il valore da sostituire e uno con il valore entrante. Se sono 
convinto che i parametri si debbano chiamare @nomecampo non risolverei 
l'ambiguit�, mentre non mi sbaglio con
"UPDATE clienti SET citt�=@cittanew WHERE citt�=@cittaold"
2. L'Add dei parametri deve essere esgeuito nella stessa sequenza in cui si 
incontrano nel commandtext. se scrivo
         cmd.Parameters.Add("param2", OleDbType.VarChar, 5, "idcliente")
         cmd.Parameters.Add("param1", OleDbType.VarChar, 15, "citt�")
anzich�
         cmd.Parameters.Add("param1", OleDbType.VarChar, 15, "citt�")
         cmd.Parameters.Add("param2", OleDbType.VarChar, 5, "idcliente")
ottengo un errore.
Sinceramente non capisco se sbaglio io qualcosa, perch� non dovrebbe essere 
cos�! Infatti, ai parametri do un nome apposta per farne riferimento 
preciso, altrimenti, se vale la posizione, il commandtext avrei potuto 
scriverlo:
      Dim upd As String = "update clienti set citt� =@ WHERE idcliente=@"
3. Tu hai fatto 3 esempi distinti per update/insert/delete. Effettivamente � 
difficile che si facciano tutte queste operazioni in un unico blocco. Tant'� 
che comunque � possibile. La precisazione da fare, utile soprattutto per il 
suggerimento successivo, � che il metodo Update dell'adapter esegue tutti i 
comandi. Quindi, se � stato definito sia l'Insertcommand che 
l'updatecommand, vengono eseguiti entrambi
4. Nel tuo esempio istanzi ogni volta un adapter e un dataset locale (cosa 
per certi versi buona e giusta). In realt�, se sto mostrando una tabella a 
video con un gridview, ho gi� questi oggetti e mi verrebbe la tenetazione di 
usare quelli. Anche perch�, se ne uso uno locale, per avere le modifiche a 
video dopo l'update dell'adapter devo eseguire un clear sul dataset cui � 
collegata la gridview e poi di nuovo un fill dall'adapter. Se invece uso il 
dataset e l'adapter che ho gi�, dopo l'update mi basta un 
dataset.acceptchange.
A questo punto la precisazione da suggerire. Se si RI-utilizza lo stesso 
oggetto per diverse operazioni di update/insert/delete (caso tipico in una 
maschera), si deve fare attenzione a:
    - eseguire un "paramters.clear" prima di definire i nuovi parametri, 
cio� se il nuovo aggiornamento definisce nuovi parametri, quelli precedenti 
vanno tolti altrimenti si sommano ai nuovi creando pasticci
    - vanno posti a nothing i comandi che non si usano pi�, cio�, per quanto 
detto al punto 3, se prima ho eseguito un comando di UPDATE, ed ora faccio 
un INSERT, il adapter.commandupdate va tolto, altrimenti il metodo 
adapter.Update(datasse, "nometab") se li ritrova entrambi e li esegue 
entrambi.
Se ho capito male qualcosa, correggimi
Ciao Gianni 

Nei tuoi esempi su insert/update/delete non viene mai eseguito l'open 
esplicito della connessione ma solo il close, ed infatti tutto funziona. Se 
ho capito bene l'open � implicito nel metodo adapter.fill. Ma allora, il 
Fill non chiude automaticamente la connesione? Io ero convinto di si, cio� 
avevo capito che Fill aprisse la connessione se non gi� aperta, quindi la 
chiudesse se prima era chiusa....
Gianni 

Rieccomi. Non ho ben capito il Command Building:
- Il tuo esempio a me non funziona..?
- Cosa vuol dire "la select deve restituire una chiave primaria"? Io ho 
definito l'adapter e il selectcommand.commandtext coma fai tu, il db access 
che uso come esempio la chiave primaria ce l'ha, ma io non specifico altro 
all'adapter sulla sua esistenza: si deve fare esplicitamente con qualche 
istruzione?
- nell'esempio viene definita la var stringa "ins", con il codice sql per 
l'INSERT, ma poi non mi sembra venga usata. Retaggio di un copia/incolla o 
me la sono persa io?
Gianni 

 scriverlo:
zac
probabilmente perchè gli esempi li fa con Jet(Access)...
nell'ordine che usa il comando...in quello li devi fornire!!
Inoltre...fatti la domanda....perchè usa i parametri?
Che stracavolo di ragione c'è?
La ragione infatti può non esserci....
se stai facendo un update o un insert...falla da codice e fornisci i
valori!
Però...c'è sempre il problema di una eventuale validazione dell'input!
E il problema grosso della SQL Injection...
una delle strategie per prevenirla prevede ANCHE l'uso dei parametri
invece del valore nudo e puro!
Ovvio che se hai già validato o NON REPUTI tu possa avere quei
problemi....togli i parametri e campa tranquillo (e un po di
millisecondi più veloce!)
I parameri sono utili per passare stringhe generiche e valorizzabili
con tipi prestabiliti di dati....sono usatissime in asp(.net) per
aggiornare tanti dati ...è tutto più legibile e pulito!
Ma ne puoi anche fare a meno se cerchi qualche millisecondo
risparmiato a giro per la tua applicazione...con tutti i rischi del
caso!

valori!
Sottoscrivo le tue osservazioni. Aggiungo che avevo imparato ad usare i 
parametri soprattutto per risolvere problemi derivanti la sintassi 
*variabile*.... intendo cose tipo una data che a volte va scritta come 
stringa racchiusa tra "", a volte tra ##, ovvero date scritte a volte come 
gg/mm/aa, a volte come gg/mm/aaaa, a volte come mm/gg/aa, a volte la 
variabile DataSeparator impostata a "/", a volte ".", ecc...... avevamo 
visto che le cose  cambiavano da PC a PC. Insomma, c'erano comandi SQL che 
su un PC andavano e su un altro no, e non ho mai capito bene se dipendesse 
da variabili di sistema, settaggi sul jet o altro. Con i parametri sono 
spariti tutti questi problemi. Ovviamente su stringhe e numeri non c'erano 
queste difficolt�.
A parere personale, se ci si abitua un attimo ad usare i parametri, anche 
nelle espressioni pi� semplici, vivi tranquillo e non costa granch�... 
almeno io ;-))
Ciao e grazie, Gianni 

 Gianni
esattamente cosï¿œ infatti ho scritto:
"e la chiude dopo aver eseguito il suo compito"


 la sono persa io?
residuo di copia/incolla
ciao!



grazie per i suggerimenti, sto mettendo on line il paragrafo 
"approfondimenti"
ciao.


 altrimenti duplica la chiave primaria e quindi genera errore.
C'ho riprovato e ora funziona anche a me...
Ciao 

 Ciao
http://www.theeasyweb.net/index.php?option=com_content&view=article&id=93:tutorial-adonet-e-vbnet-lez-13b-approfondimenti&catid=41:appunti-adonet&Itemid=64
thanks
