469,945 Members | 2,014 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,945 developers. It's quick & easy.

IDbDataAdapter e RowUpdating

Ciao a tutti,
sto cercando di realizzare una classe (ProviderFactory) che mi consenta di
scrivere del codice a prescindere dal provider utilizzato per accedere ai
dati. Al momento gestisco i classici SqlClient, ODBC, OleDb e Oracle.
Ho dichiarato nel codice client le variabili utilizzando le interfacce
(IDbConnection, IDbCommand, ecc..) Il codice funzionava alla grande finch
non mi sono imbattuto nel seguente problema:

IDbDataAdapter non supporta gli eventi RowUpdating e RowUpdated, a
differenza degli equivalenti oggetti (SqlDataProvider, ecc...).
Tali eventi sono ovviamente indispensabili per eseguire delle update
complesse o anche per solo scopo di debug.
Come posso fare a scrivere del buon codice ObjectOriented senza rieseguire
il cast all'indietro ?

Ogni idea ben accetta. Grazie

Maurizio
Jul 21 '05 #1
4 1536
Quale e' il problema usando la classe astratta DataAdapter come base class e
fargli implementare la IDbDataAdapter come fa il framework? (magari mi sono
perso qualcosa...)

HTH

--
Corrado Cavalli [Microsoft .NET MVP-MCP]
UGIdotNET - http://www.ugidotnet.org
Weblog: http://www.ugidotnet.org/710.blog


Jul 21 '05 #2
L'idea di avere nel codice client delle istruzioni come le seguenti:

Dim pf As New MyProviderFactory
Dim cb As MyCommandBuilder

Dim cn As IDbConnection
Dim cmm As IDbCommand
Dim da As IDataAdapter
Dim db As IDbDataAdapter
Dim currDs As DataSet

Dim Connection As String
Dim SqlCommand As String

Connection = TxtConnection.Text
SqlCommand = TxtStatement.Text

pf.Provider = ProviderType.SqlServer

cn = pf.CreateConnection(Connection)
da = pf.CreateDataAdapter(SqlCommand, cn)
db = CType(da, IDbDataAdapter)
currDs = New DataSet
db.Fill(currDs)
DGData.DataSource = currDs
currDataSet = currDs

Tranne dove specificato il tipo di connessione (pf.Provider =
ProviderType.SqlServer) il codice assolutamente generico e prescinde dal
provider utilizzato. La mia idea di far uso degli eventi esposti dai
DataAdapter (RowUpdating, RowUpdated) ma, utilizzando il codice precendete,
non posso agganciarmi in quanto IDbDataAdapter non espone gli eventi. Ho
verificato che anche la classe base DBDataAdpater non espone alcun evento.

"Corrado Cavalli [MVP]" <co*****************@mvps.org> wrote in message
news:#M**************@tk2msftngp13.phx.gbl...
Quale e' il problema usando la classe astratta DataAdapter come base class e fargli implementare la IDbDataAdapter come fa il framework? (magari mi sono perso qualcosa...)

HTH

--
Corrado Cavalli [Microsoft .NET MVP-MCP]
UGIdotNET - http://www.ugidotnet.org
Weblog: http://www.ugidotnet.org/710.blog

Jul 21 '05 #3
Ti consiglio di dare un'occhiata alla bella presentazione di Andrea
Saltarello su ado.net al link:
http://www.ugidotnet.org/workshops/w...x?WorkshopID=5

Uno degli esempi proprio chiamato AbstractADO per realizzare ci che vuoi.

Il problema principale che le interfacce delle ado supportano il minimo
comun denominatore delle classi Sql, Oledb, Oracle,...
Perci la risposta non pu essere quella pi ovvia di usare le interfacce
come mezzo per arrivare a sfruttare la totale potenza dei vari provider.
Per esempio Sql supporta ExecuteXmlReader e tu potresti decidere di
sopperire alla mancanza di questo metodo negli altri provider.

Un buono spunto viene da quell'esempio di Andrea.

--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com
UGIdotNET - User Group Italiano .NET http://www.ugidotnet.org

"Maurizio" <ma*******************************@cezannesw.com > wrote in
message news:O1**************@TK2MSFTNGP12.phx.gbl...
L'idea di avere nel codice client delle istruzioni come le seguenti:

Dim pf As New MyProviderFactory
Dim cb As MyCommandBuilder

Dim cn As IDbConnection
Dim cmm As IDbCommand
Dim da As IDataAdapter
Dim db As IDbDataAdapter
Dim currDs As DataSet

Dim Connection As String
Dim SqlCommand As String

Connection = TxtConnection.Text
SqlCommand = TxtStatement.Text

pf.Provider = ProviderType.SqlServer

cn = pf.CreateConnection(Connection)
da = pf.CreateDataAdapter(SqlCommand, cn)
db = CType(da, IDbDataAdapter)
currDs = New DataSet
db.Fill(currDs)
DGData.DataSource = currDs
currDataSet = currDs

Tranne dove specificato il tipo di connessione (pf.Provider =
ProviderType.SqlServer) il codice assolutamente generico e prescinde dal
provider utilizzato. La mia idea di far uso degli eventi esposti dai
DataAdapter (RowUpdating, RowUpdated) ma, utilizzando il codice precendete, non posso agganciarmi in quanto IDbDataAdapter non espone gli eventi. Ho
verificato che anche la classe base DBDataAdpater non espone alcun evento.

"Corrado Cavalli [MVP]" <co*****************@mvps.org> wrote in message
news:#M**************@tk2msftngp13.phx.gbl...
Quale e' il problema usando la classe astratta DataAdapter come base
class e
fargli implementare la IDbDataAdapter come fa il framework? (magari mi

sono
perso qualcosa...)

HTH

--
Corrado Cavalli [Microsoft .NET MVP-MCP]
UGIdotNET - http://www.ugidotnet.org
Weblog: http://www.ugidotnet.org/710.blog


Jul 21 '05 #4
Grazie,
ho scaricato il codice e le slides. Spero che possano essermi utili.

Maurizio
"Raffaele Rialdi [MVP]" <malta@n0spam_vevy.com> wrote in message
news:#x**************@TK2MSFTNGP12.phx.gbl...
Ti consiglio di dare un'occhiata alla bella presentazione di Andrea
Saltarello su ado.net al link:
http://www.ugidotnet.org/workshops/w...x?WorkshopID=5

Uno degli esempi proprio chiamato AbstractADO per realizzare ci che vuoi.
Il problema principale che le interfacce delle ado supportano il minimo
comun denominatore delle classi Sql, Oledb, Oracle,...
Perci la risposta non pu essere quella pi ovvia di usare le interfacce
come mezzo per arrivare a sfruttare la totale potenza dei vari provider.
Per esempio Sql supporta ExecuteXmlReader e tu potresti decidere di
sopperire alla mancanza di questo metodo negli altri provider.

Un buono spunto viene da quell'esempio di Andrea.

--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com
UGIdotNET - User Group Italiano .NET http://www.ugidotnet.org

"Maurizio" <ma*******************************@cezannesw.com > wrote in
message news:O1**************@TK2MSFTNGP12.phx.gbl...
L'idea di avere nel codice client delle istruzioni come le seguenti:

Dim pf As New MyProviderFactory
Dim cb As MyCommandBuilder

Dim cn As IDbConnection
Dim cmm As IDbCommand
Dim da As IDataAdapter
Dim db As IDbDataAdapter
Dim currDs As DataSet

Dim Connection As String
Dim SqlCommand As String

Connection = TxtConnection.Text
SqlCommand = TxtStatement.Text

pf.Provider = ProviderType.SqlServer

cn = pf.CreateConnection(Connection)
da = pf.CreateDataAdapter(SqlCommand, cn)
db = CType(da, IDbDataAdapter)
currDs = New DataSet
db.Fill(currDs)
DGData.DataSource = currDs
currDataSet = currDs

Tranne dove specificato il tipo di connessione (pf.Provider =
ProviderType.SqlServer) il codice assolutamente generico e prescinde dal provider utilizzato. La mia idea di far uso degli eventi esposti dai
DataAdapter (RowUpdating, RowUpdated) ma, utilizzando il codice

precendete,
non posso agganciarmi in quanto IDbDataAdapter non espone gli eventi. Ho
verificato che anche la classe base DBDataAdpater non espone alcun evento.
"Corrado Cavalli [MVP]" <co*****************@mvps.org> wrote in message
news:#M**************@tk2msftngp13.phx.gbl...
Quale e' il problema usando la classe astratta DataAdapter come base

class
e
fargli implementare la IDbDataAdapter come fa il framework? (magari mi

sono
perso qualcosa...)

HTH

--
Corrado Cavalli [Microsoft .NET MVP-MCP]
UGIdotNET - http://www.ugidotnet.org
Weblog: http://www.ugidotnet.org/710.blog



Jul 21 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Vaap | last post: by
4 posts views Thread by Maurizio | last post: by
reply views Thread by Steven Nagy | last post: by
reply views Thread by merco | last post: by
3 posts views Thread by slemen | last post: by
3 posts views Thread by nick chan | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.