Data provider run-time information

  • Thread starter Thread starter Edward Diener
  • Start date Start date
E

Edward Diener

How does one get data provider information at run-time using ADO .NET. I
want to get such things as particularities of SQL syntax, transaction type
support, other data provider specific information but I want to do it in a
generic way and not in a hard-coded, predetermined way. I recall under OleDb
there were database properties which one could get. What is the equivalent
classes for this in ADO .NET ?
 
That is very difficult to do in a generic way that works for all
providers equally because each provider is so different. SQL syntax,
parameter delimiters, stored procedures, etc., are all specific to
individual providers. The System.Data.Common namespace contains
classes that are shared by all of the managed providers, but when you
need to drill down into particulars you will want to work with
specific providers such as SqlClient, OracleClient, or OleDb.

--Mary
 
Mary Chipman said:
That is very difficult to do in a generic way that works for all
providers equally because each provider is so different. SQL syntax,
parameter delimiters, stored procedures, etc., are all specific to
individual providers. The System.Data.Common namespace contains
classes that are shared by all of the managed providers, but when you
need to drill down into particulars you will want to work with
specific providers such as SqlClient, OracleClient, or OleDb.
Click to expand...

I can understand doing this for SqlClient or OracleClient, or any other
specific provider set of classes. But OleDb is not a specific provider set
of classes nor is Odbc. The providers for that are determined at run-time.
In ADO, one could use the Properties collections of connect, command, and
recordset to get RDBMS specific information at run-time because ADO was
built on top of OLEDB. How does one do this in ADO .NET ? Microsoft just
throwing up their hands and telling the programmer to now hard-code this
information is not an advance in programming paradigms but a step backward.
APIs like ODBC, OLEDB, and ADO were meant to overcome.the shortcomings of
coding for a specific RDBMS. Now I am being told that in the area of RDBMS
specific syntax and usage I need to hard-code database solutions ?

Not providing run-time access to RDBMS properties, at least for OleDb and
Odbc where such information does exist in the original APIs, is a very poor
design decision by Microsoft.
 
There are some things that today you either have to hard-code or
provide wrappers for on your own, depending on your data source and
what kind of information you need to get out of it. ADO.NET 2.0 will
take you further since the classes in the System.Data.Common namespace
have been expanded to make writing generic code easier, but it's still
in beta, subject to change, and may not deliver 100% of everything you
may want.

--Mary
 
Mary Chipman said:
There are some things that today you either have to hard-code or
provide wrappers for on your own, depending on your data source and
what kind of information you need to get out of it.
Click to expand...

Someone writing a generic component can not possibly know all of the
different data sources in advance which an end-programmer might want to use.
Creating wrappers for some database systems and then giving up on all others
because Microsoft has not provided a generic way to find out certain needed
information, is certainly not the way to program or please one's customers
or organization when attempting to create generic code. Given that there has
to be a dividing line between what RDBMS specific information is provided by
ADO .NET, still some subset of all the possible areas of information should
be implemented. What is really strange is that a particularly useful subset
existed in ODBC, was enhanced in OLEDB, which was carried over into ADO, and
then is practically gone with ADO .NET. I realize that ADO .NET is
different, that it uses C++-like interface polymorphism and specific RDBMS
classes rather than ActiveX objects, which is certainly better in my
opinion, but that is no reason for just dropping all that previously
established useful functionality.
ADO.NET 2.0 will
take you further since the classes in the System.Data.Common namespace
have been expanded to make writing generic code easier, but it's still
in beta, subject to change, and may not deliver 100% of everything you
may want.
Click to expand...

That is a nice disclaimer but it is not needed since, aside from the
information that the next release may have more information, you are not
telling me anything certain. Hopefully ADO .NET 2.0 will be much better in
the regard of generic RDBMS information, with some means of accessing a
great deal more functionality than the current release.
 
If there is specific functionality that you really need badly today
that is not available in ADO.NET, you may need to write your own
unmanaged DLL or use COM interop to get to those APIs. The team is
working on this, it hasn't been abandoned, but no one can say at this
point what specific functionality will ship in ADO.NET 2.0.

--Mary
 
Back
Top