[***] Usare DataReader e oggetti Command è corretto?

[RAVALON]

Salve....

non mi sono ancora ripreso dalla morte dei recordset

Siccome nei miei progetti la maggior parte delle azioni sono di lettura, utilizzo un DataReader per le select da mostrare in una griglia e faccio le modifiche dispositive INSERT,UPDATE,DELETE via SQL con degli oggetti Command...

Vorrei un parere da voi....
è una tecnica performante e corretta questa ?

I dataset non mi piaccio al momento (poi imparerò) e mi torna più comodo usare query SQL per gli aggiornamenti...

Quanto sbaglio in questo ?

[raffaeu]

Allora la MSDN consiglia se hai dati a tipizzazione forte, lavorando con i DS e i contorni lavori meglio.

Io pero' leggo i dati da macchine remote AS400 e lavoro in maniera piu' performante con DataReader e COmmand, che popolano pero' a runtime dei Dataset ... questo perchè mi trovo benissimo con i DataRelation etc ...

Devi fare tutte le prove del caso perchè per ogni situazione e necessità possono servire i Ds o esserti solamente di impiccio ...

[alka]

Originariamente inviato da RAVALON
Salve....
non mi sono ancora ripreso dalla morte dei recordset

Io stapperei una bottiglia di spumante, invece.

Originariamente inviato da RAVALON
Siccome nei miei progetti la maggior parte delle azioni sono di lettura, utilizzo un DataReader per le select da mostrare in una griglia e faccio le modifiche dispositive INSERT,UPDATE,DELETE via SQL con degli oggetti Command...

Dici che i tuoi progetti sono per la maggior parte "di lettura", poi dici che esegui INSERT, UPDATE e DELETE...

Originariamente inviato da RAVALON
Vorrei un parere da voi....
è una tecnica performante e corretta questa ?

Difficile rispondere a questa domanda. Diciamo che non so quanto sia efficiente e produttivo rifare tutto ciò che nel framework esiste già ed è utilizzabile.

Originariamente inviato da RAVALON
I dataset non mi piaccio al momento (poi imparerò) e mi torna più comodo usare query SQL per gli aggiornamenti...
Quanto sbaglio in questo ?

Quando si scarta una soluzione viabile per "antipatia", credo che si commetta un errore per principio.

P.S.: il linguaggio va indicato nel titolo come da Regolamento; hai aperto due discussioni in cui non era presente.

[raffaeu]

E Questo è il terzo ...

Oggi Alka si è alzato con la falciatrice in mano ...

[RAVALON]

mi scuso per il titolo....in futuro starò attento...promesso

Dico di fare quasi esclusivamente letture.....ma anche insert...cosa c'è di strano ???

La maggior parte delle azioni sono di estrazioni dati da un DB....poi solo alcuni utenti possono fare modifiche....per cui torna se dico che la maggior parte delle azioni è di sola lettura....

....mi sembra che per la lettura il DataReader sia più veloce....

Bene...forse devo ancora documentarmi un po' prima di scartare eventuali tipologie di progettazione....

Non dico che la morte dei recordset sia un male...solo che io mi ci trovavo bene....tutto qui...

[alka]

Originariamente inviato da RAVALON
Dico di fare quasi esclusivamente letture.....ma anche insert...cosa c'è di strano ???
La maggior parte delle azioni sono di estrazioni dati da un DB....poi solo alcuni utenti possono fare modifiche....per cui torna se dico che la maggior parte delle azioni è di sola lettura....

Sì, ma è ininfluente. Se devo prevedere che l'utente possa aggiornare un insieme di record, che questo avvenga sempre o solo quale volta non cambia il fatto che si debba implementare l'aggiornamento del record comunque.

Se è necessario aggiornare i record in certe condizioni, l'aggiornamento va implementato, indipendentemente dal fatto che vi sia una probabilita dell'1% o del 100% di ricadere in quel caso.

Che tu faccia esclusivamente letture e abbia bisogno ogni tanto di fare un aggiornamento, non cambia la realtà delle cose e cioè che devi codificare l'aggiornamento, no?

Riassumendo, non mi sembra un'informazione significativa per il problema.

Originariamente inviato da RAVALON
....mi sembra che per la lettura il DataReader sia più veloce....

Se devi solamente leggere i dati, e devi farlo in modalità unidirezionale, è senz'altro più rapido del DataSet che deve comunque provvedere a memorizzare i dati che legge, ma poi con il DataReader i dati non riesci ad aggiornarli se non eseguendo comandi SQL; se devi eseguire comandi su un record, devi memorizzare i suoi indici e i dati precedenti, devi memorizzare le modifiche dell'utente, insomma devi fare tutto ciò che la combinata DataSet+DataAdapter fanno.

Originariamente inviato da RAVALON
Non dico che la morte dei recordset sia un male...solo che io mi ci trovavo bene....tutto qui...

Sono piuttosto limitati. Basta semplicemente acquisire dimestichezza con le classi ADO.NET per risolvere il problema.

Ciao!

[RAVALON]

concordo con te che di sicuro l'evoluzione di .NET ha grandi vantaggi....e sono consapevole che quando avrò chiara la situazione forse mi sentirò stupido ad avere chiesto certe cose....
ma un forum serve anche a questo no ?

...non vedevo grossi problemi con i recordset in quanto bastava in fondo lanciare dei comandi SQL , se vuoi mirati ad un record particolare con una semplice condizione WHERE e modificavi quel che volevi....

senza usare altri due oggetti che si rimbalzano dati per poi fare comunque una modifica sul DB esattamente come potrebbe fare una query SQL secca....

Anche per quanto riguarda l'estrazione...
Prima aprivi un recordset, associavi i dati ad un AdoTable e fine dei giochi...tutto sempre sotto controllo, dati presenti per qualsiasi cosa in ogni momento....

Ora devo prima caricare un Dataset...che però da solo non riesce a fare molto se non una copia del DB....
poi lo devo associare ad un datatable o dataadapter perchè possa fare delle modifiche o semplicemente visualizzare i dati in una griglia....

cioè...non voglio mica polemizzare...anzi....vorrei capire...

mi spieghi tu che te ne intendi dove stà il vantaggio di dover usare diversi controlli quando si può fare tutto con un comando (parlo per quanto riguarda l'aggiornamento) ? vediamo se riesco a capire cosa mi perdo perchè ancora non l'ho capito

E poi...dato che è stata lasciata la possibilità di fare le stesse cose con i COMMAND...dico...ci sarà un motivo ? o è stato lasciato solo per retrocompatibilità ?

[RAVALON]

riporto una discussione che avevo postato in un nuovo topic che è stato giustamente chiuso per violazione delle regole...su invito a continuare su questa ci riprovo in termini più generali..spero di non andare di nuovo in conflitto col regolamento...

-----------------------------------------------
Sull'onda del volere imparare ADO.NET venendo da ADO sto cercando di capire le modalità migliori per lavorare

In particolare in questo post vi chiedo quando è il caso di lavorare in maniera connessa(datareader) e quando in maniera disconnessa(dataset)

Io mi troverei bene a usare un datareader e degli oggetti command per eseguire gli update sul db....
In un solo passaggio riempio una griglia di dati da visualizzare per i miei gestionali.....con una query SQL aggiorno i dati e fine di ogni problema....

Provando a lavorare coi Dataset vedo che c'è molto codice da inserire se non si usano i wizard(che detesto perchè devo sapere cosa faccio in ogni riga di codice)....
....prima devo utilizzare un DataAdapter per popolare un dataset, poi devo aggiornare il dataset con dei comandi che non mi sembrano molto intuitivi e fanno largo uso di punteggiatura che diminuisce la velocità di esecuzione, poi ancora devo fare l'aggiornamento al db vero e proprio.....

Molto casino quando posso invece aggiornare il db con un semplice comando SQL che tra l'altro è universale(+ o -)

Vi chiedo quindi di illuminarmi o voi che siete da sempre i miei guru per lo sviluppo sulle differenze di utilizzo e magari di spiegarmi qual'è il vantaggio nell'uso di un Dataset a parte il fatto che posso tirarci fuori i dati da qualsiasi fonte dati....

Ho grossi dubbi sull'utilità di un dataset ma voglio saperne di più....ho comperato due libri ma l'argomento non viene quasi mai trattato a sufficienza, a dispetto dell'importanza e della complessità della tematica...

Grazie

[yyzyyz]

leggi questo articolo tratto dall'Msdn

Differenze tra ADO.NET e ADO

[RAVALON]

ti ringrazio...mi sono letto diverse pagine...

A quanto capisco di miglioramenti ce ne sono, ma vanno a vantaggio di progetti medio grandi...

Nel caso di piccoli gestionali mono-utente come il mio è ininfluente come si legge anche dalle pagine che mi hai linkato....

Comunque sia iniziero' ugualmente a usare il nuovo ADO.NET se non altro per restare al passo coi tempi....

E comunque sia, rimango ancora dell'opinione che per reperire i dati dei campi estratti è necessario più codice che tra l'altro fa uso di molta punteggiatura che abbassa la velocità di esecuzione...

Con ADO per reperire un campo bastava fare un semplice
controllo=DataControl("nomecampo")

oppure

controllo.text=Recordset("nomecampo")

ora bisogna usare gli insiemi...scorrere le righe specificare il dataset, la tabella, quale riga, quale colonna e infine estrarre il campo.....è quello che non mi sembra un grande guadagno