General Upgrade Issues from ADO to ADO.NET

for RuBoard

You have a number of architectural issues to consider when converting your codebase to work within the managed code of the Microsoft .NET Framework. ADO.NET walks a fine line: The ADO.NET object model is similar enough to ADO as to be instantly familiar to an ADO developer, yet your ADO code will not work without modifications in a .NET Windows form or Web form application. If you've worked with ADO, you're going to feel at home with ADO.NET, but you're going to have to spend a significant amount of time upgrading your codebase.

The next few sections discuss some of the major architectural changes you'll face upgrading from ADO to ADO.NET.

ADO.NET Completely Disconnected

ADO.NET is a completely disconnected set of data access objects. This means that, unlike ADO, it is impossible to bind a table directly to a control, like the DataGrid . ADO.NET objects connect to the data source, retrieve the data (and related schema), thus creating a snapshot, which you can use as you please .

A number of benefits are associated with a disconnected set of data access objects, the most important of which is scalability. Creating and maintaining an open connection to a database is a very costly procedure, in terms of memory and licensing. For a single- user standalone Visual Basic 6.0 application using a Microsoft Access database, this is not an issue. However, when you consider a Visual Basic 6.0 application supporting multiple users or a Web application with thousands of potential simultaneous users, the disconnected view of data makes more sense.

Therefore, any legacy code that makes use of a server-side cursor to navigate records or any objects that bind directly to database objects will have to be examined closely and in most cases re-engineered.

ADO.NET Is Strongly Typed

All database results in ADO are returned as a Variant data type, and then converted. The Variant data type is roughly analogous to the Object type in the Microsoft .NET Framework. The Variant data type carries a large amount of associated overhead by default. Conversely, in ADO.NET, you can access columns returned from the database using their native data types. As you might have guessed, the ADO types and their corresponding ADO.NET types do not match up exactly. Table 16.1 shows a list of ADO types and their corresponding ADO.NET data types, which you can use in your code conversions.

Table 16.1. ADO Versus ADO.NET Data Types
Code Symbol
adEmpty null
adBoolean Int16
adTinyInt SByte
adSmallInt Int16
adInteger Int32
adBigInt Int64
adUnsignedTinyInt promoted to Int16
adUnsignedSmallInt promoted to Int32
adUnsignedInt promoted to Int64
adUnsignedBigInt promoted to Decimal
adSingle Single
adDouble Double
adCurrency Decimal
adDecimal Decimal
adNumeric Decimal
adDate DateTim e
adDBDate DateTim e
adDBTime DateTim e
adDBTimeStamp DateTim e
adFileTime DateTim e
adGUID Guid
adError ExternalException
adIUnknown object
adIDispatch object
adVariant object
adPropVariant object
adBinary byte[]
adChar string
adWChar string
adBSTR string
adChapter not supported
adUserDefined not supported
adVarNumeric not supported
for RuBoard

Sams Teach Yourself ADO. NET in 24 Hours
Sams Teach Yourself ADO.NET in 24 Hours
ISBN: 0672323834
EAN: 2147483647
Year: 2002
Pages: 237 © 2008-2017.
If you may any questions please contact us: