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