E
Emmanuel Gravino
If i am to support both access db and sql server, should i simply use OleDb
and forget about SqlClient?
and forget about SqlClient?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
C
CT
I would probably use both, as you'd otherwise loose the performance of the
SqlClient.
SqlClient.
C
CT
For the connected layer (Connection, Command, DataAdapter etc.) , I simply
use SqlClient or OleDb. The disconnected layer (DataSet, DataTable etc.) is
the same for both.
As for an overhead I guess the answer is yes; you're using two classes from
different namespaces, but are you using them at the same time?
use SqlClient or OleDb. The disconnected layer (DataSet, DataTable etc.) is
the same for both.
As for an overhead I guess the answer is yes; you're using two classes from
different namespaces, but are you using them at the same time?
E
Emmanuel Gravino
i'm writing an application that must be able to access data both from sql
server and access db (not at the same time... depends on how the end user
configures the app).
I was thinking of implementing a method that selects the connection, command
dataadapter family depending on the database backend the user had
configured. But this requires to have both oledb and sqlclient.
I wanted to find out a better way of dealing with this.
server and access db (not at the same time... depends on how the end user
configures the app).
I was thinking of implementing a method that selects the connection, command
dataadapter family depending on the database backend the user had
configured. But this requires to have both oledb and sqlclient.
I wanted to find out a better way of dealing with this.
C
CT
Well, then your only option is the OLE DB .NET provider or even the ODBC
..NET Data Provider (which is faster than OLE DB BTW). Nothing wrong with
that, except for loosing the raw performance of a native .NET Data Provider.
..NET Data Provider (which is faster than OLE DB BTW). Nothing wrong with
that, except for loosing the raw performance of a native .NET Data Provider.
E
Emmanuel Gravino
thanks for your feedback... i'll check what exactly are these performance
benefits and base my descision on whether its worth the effort
benefits and base my descision on whether its worth the effort