Couple of ADO.NET 2.0 Questions

[J. Ambrose Little [MVP]]

I've got a couple of ADO.NET 2.0 questions that I thought I'd post here to
see what you all think.

Question One (regarding new SqlTypes):
I ran across the new types, but the current docs online at msdn2 and in the
2005 BOL do not provide any details. The types I'm unfamiliar with are:
SqlBytes, SqlChars, SqlStreamChars, and SqlXml. I think it's fairly obvious
what they're for, but I'd like to get more in-depth information about them.

There're also a bundle of *ImporterExtension types and a new StorageState
enum. Is there any advance documentation available on these types that
would help me write about them?

Second Question (more general):
Also, the docs (for 2003 and 2005) note that using SqlTypes will increase
perf because "other data types are converted to and from SqlTypes behind the
scenes." It's not really clear to me what this means, i.e., what "other
data types" are involved and in what situations this conversion would occur.
In what context does using SqlTypes offer better perf? Can anyone illumine
this topic?

Thanks.

 

[Kevin Yu [MSFT]]

Hi J. Ambrose Little,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you have 2 questions. The first is you
need to know some detail about the Sql data types in ADO.NET 2005. Second,
you need to know what does "other data types are converted to and from
SqlTypes behind the scenes." mean. If there is any misunderstanding, please
feel free to let me know.

For the first question, since Visual Studio .NET 2005 hasn't been released
yet, so the official document hasn't been release. Currently, we don't have
such detailed documents on these data types. You can try to find help in
the VS.NET 2005 newsgroups in from the following link:

http://communities.microsoft.com/newsgroups/default.asp?icp=whidbey&slci
d=us

For the second question, when data are first get from the SQL Server
database, their types are Sql types. Then the .NET framework internally
converts them to .NET framework types. So, if you use DataReader to
manipulate on Sql types directly, it will be faster.

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

 

[Mary Chipman]

The documentation for SqlTypes in Whidbey is still "under
construction", but will be in the Whidbey beta 2 docs. SqlTypes will
be directly supported in the DataSet/DataTable, meaning you can create
a DataColumn of a SqlType instead of a CLR type, so you get
strongly-typed DataSets (performance gain). SqlBytes, SqlChars etc.
wrap buffer or stream of SqlChar Sqlbytes, etc. SqlXml represents XML
data retrieved from the server. The ImporterExtension types and
StorageState are not intended to be used in your code and are intended
to support internal Framework functionality. You may or may not see
them in the RTM build--that hasn't been determined yet.

HTH,

--Mary

 

[J. Ambrose Little [MVP]]

Hi Kevin,

Yes, you more or less seem to get my questions. For the first, I am
pursuing other avenues to get more information now.

For the second, now that you point me in the right direction, I see (in
Reflector) that SqlDataReader returns SqlTypes. So that is the context in
which the docs mean things will be more efficient if we use them.
Otherwise, we have to convert to the .NET primitive types when getting them
from the DR. I also hear that v2 will use SqlTypes in the DataTable (as
column types) for perf improvements. This makes sense in that context. May
I suggest that Microsoft elaborate more in the docs on this potential
performance increase and provide scenarios where it makes sense to go that
route, e.g., if you are binding directly to a SqlDR or DataView?

For those of us using object-oriented design, n-tier architecture, etc.
where we are using strongly-typed collections and such, I don't think it
really makes sense to use SqlTypes for the type members in our domain
objects. After all, gearing towards a loosely-coupled architecture, we
wouldn't want to gear ourselves specifically to a SQL Server back end. (I
understand that SqlTypes are not inherently tied to SQL Server.)

Sure, SqlDataReader is optimized for SqlTypes, but there's no guarantee that
other providers will do that, right? Do you know if the other popular RDBMS
providers make use of SqlTypes in a similar manner? Is there any reason
they weren't named DbTypes, NullableTypes, or something more generic?

In any case, thanks for the information.

 

[Kevin Yu [MSFT]]

Hi J. Ambrose Little,

Thanks for you suggestions. I will forward these to the corresponding
group. As you know, other managed data providers like Oracle, for example,
have optimized types in System.Data.OracleClient namespace.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."