Upgrading Data Access

Each new version of Visual Basic has delivered enhancements to data access; Visual Basic .NET is no exception. This chapter will show you how to upgrade Visual Basic 6.0 data access to .NET, covering the three major data access technologies (ADO, DAO and RDO) in different scenarios. Additionally, you will learn to convert VB6 Data Reports to .NET Crystal Reports.

• What is the first thing that should be taken into account before upgrading a Visual Basic 6.0 data access code?
• Will the Visual Basic upgrade wizard automatically convert all ADO data binding to .NET?
• What kinds of data binding does Visual Basic.NET support?
• In a VB 6.0 to VB.NET project without ADO Data Binding, how does the automatic upgrade work?
• Which tasks can Visual Basic 6.0 developers accomplish with Data Environment?
• What happens when I use the upgrade wizard to migrate an application that uses Data Environment?
• How is the Data Environment with Data Binding converted by the Upgrade Wizard?
• What is the best strategy for converting DAO and RDO data access technologies to .NET Framework?
• What are some important considerations that should be taken into account when upgrading DAO technology to ADO?
• And when the upgrade to ADO is performed from RDO technology, what should I contemplate?
• What happens when I upgrade an application that contains Remote Data Control Technology?
• What are custom data access components?
• What upgrade alternatives do I have for applications that use custom data access components?
• If the application uses different technologies such as ADO, RDO, DAO and custom data access, what’s the best way to go?
• How are VB 6.0 Data Reports converted to .NET ?

What is the first thing that should be taken into account before upgrading a Visual Basic 6.0 data access code?

There are many Visual Basic applications that store their data in a database system such as SQL Server or Microsoft Access. Each one uses different approaches to access the data, such as ADO with data binding or RDO without data binding. That is why before upgrading your data access code, you should analyze it to identify what type of data access it is using. The process to upgrade data access code depends on the technology used and whether data binding is used.

Will the Visual Basic upgrade wizard automatically convert all ADO data binding to .NET?

Normally, most ADO code is upgraded automatically by the upgrade wizard. With minimal manual changes, your application and Data Access technology will work the same way that it works in Visual Basic 6.0. For example, it may be necessary to add a reference to the ADODB.NET assembly (Adodb.dll) instead of the Interop.ADODB.dll that is automatically referenced by the upgrade wizard.

There are problems with the upgrade of data binding in intrinsic controls set at run time. These kinds of controls are upgraded to native Visual Basic .NET, and the DataSource, DataMember, and DataField are not upgraded by the upgrade wizard. Data binding at design time is also not supported, and the upgrade wizard does not add any binding variable or procedures, requiring you to make changes to the upgraded code.

What kinds of data binding does Visual Basic.NET support?

Visual Basic .NET only supports ADO data binding. DAO or RDO data binding are not supported. ADO data binding is supported because it is built into the COM library that manages ADO data binding in Visual Basic 6.0. Its equivalent is available in the compatibility library in Visual Basic .NET, Microsoft.VisualBasic.Compatibility.Data. This library manages data binding in Visual Basic .NET. As a result, the properties, methods, and events are compatible between the two versions of the language, which allows ADO Control and Data Environment to be automatically upgraded.

In a VB 6.0 to VB.NET project without ADO Data Binding, how does the automatic upgrade work?

An application falls into this upgrade scenario when its project references Microsoft ActiveX Data Objects but does not contain an ADO Data Control. In this case, all data access is managed directly at run time.

The automatic upgrade of a project that accesses a database without the use of data binding does not require changes in the upgraded code. The upgrade wizard automatically adds the reference to Microsoft.VisualBasic.Compatibility library, which contains ADO. All ADO code works without any modifications and has the same behavior as in the original Visual Basic 6.0 project.

However, there is a difference between the upgraded code and the original source code with respect to how a field in a recordset is accessed. In Visual Basic 6.0, it is common to access fields using the shorthand coding convention

RecordsetName!FieldName. In Visual Basic .NET the code needs to be expanded to resolve the default properties.

Which tasks can Visual Basic 6.0 developers accomplish with Data Environment?

With Data Environment, Visual Basic 6.0 developers can accomplish the following tasks:

• Create ADO Connection objects.
• Create ADO Command objects that are based on stored procedures, tables, views, synonyms and SQL statements.
• Create hierarchies of commands that are based on a grouping of Command objects or by relating one or more Command objects together.
• Write and run code that reads and sets properties of objects hosted in Data Environment.
• Execute commands included in Data Environment as programmatic, run-time methods.
• Bind Form controls to commands hosted in Data Environment.
• Create aggregates that automatically calculate values within any command hierarchy.

What happens when I use the upgrade wizard to migrate an application that uses Data Environment?

When you use this automated migration tool to convert an application that uses Data Environment, the following changes are made:

• For each Data Environment in your Visual Basic 6.0 project, a class with the name DataEnvironment prefixed to the Data Environment’s name is created and a variable named with Data Environment’s name is instanced in a module.
• For each connection and recordset hosted by a Data Environment object, a PublicWithEvents member variable with the same name is created.
• For each command, a public method with the same name is created. It will be available in the same way that its respective command is available in Visual Basic 6.0.

How is the Data Environment with Data Binding converted by the Upgrade Wizard?

Because the WinForms library that is used by Visual Basic .NET is optimized for the ADO.NET data access library, WinForms controls cannot be directly bound to ADO Recordsets. To enable binding between WinForms and ADO, the upgrade wizard uses the MBindingCollection and MBinding objects of the Microsoft.VisualBasic.Compatibility.Data library. It adds two new procedures that are used to add and remove the data binding of your controls. However, the visual management of the commands of Data Environment is lost. If you want to manage your data and data binding visually, you have to move your ADO code to ADO.NET.

What is the best strategy for converting DAO and RDO data access technologies to .NET Framework?

In Visual Basic .NET, Visual Basic Forms has been replaced with Windows Forms, a redesigned forms package. The designers of Windows Forms decided not to build DAO and RDO data binding into Windows Forms; therefore, DAO and RDO data binding are not supported.

In most of the cases, the best strategy is to first replace them with ADO and to then upgrade them to ADO.NET. This way, the long term goal of upgrading DAO and RDO technologies is broken into intermediate goals that provide various levels of functionality along the way.

It is possible to keep using DAO and RDO in Visual Basic .NET, as long as you do not use data binding with these technologies. But given the effort that is required to keep these technologies when you convert your application to Visual Basic .NET, it is probably easier to replace them with ADO in Visual Basic 6.0 before you start the migration.

After you replace DAO and RDO with ADO in your original code, almost all of the remaining upgrade work is done for you automatically by the upgrade wizard.

What are some important considerations that should be taken into account when upgrading DAO technology to ADO?

You must analyze two possible scenarios:

DAO with Data Binding. You must make some manual changes in the upgraded code because DAO data binding is not supported in Visual Basic .NET.

Code that uses DAO at run time is upgraded correctly by the upgrade wizard; it uses a wrapper to the DAO library, but you must manually recode all of the data control code if you want to maintain the data binding in your project. The best strategy is to replace your data control with an ADO Data Control before you upgrade your project to Visual Basic .NET.

DAO without Data Binding. When an application like this is upgraded to Visual Basic .NET, the upgrade wizard adds DAO library a wrapper to the new project. As a result, code that uses DAO data objects does not require manual changes, and the behavior is the same as it is in Visual Basic 6.0.

And when the upgrade to ADO is performed from RDO technology, what should I contemplate?

Also, two possible scenarios arise:

RDO with Data Binding. After you upgrade an application like this, the Remote Data Control appears to be upgraded. However, the new control is read-only at run time, and you will not be able to navigate between the results. You can correct this by changing the Remote Data Control of the upgraded project to an ADODC control in the Microsoft.VisualBasic.Compatibility.Data library. However, it is more efficient to replace the RDO technology with ADO technology in the Visual Basic 6.0 application before you upgrade the application.

RDO without Data Binding. The upgrade of the RDO code is automatic, because the upgrade wizard creates a reference to the RDO library. Your application maintains the same RDO instructions in its code, which results in the same Visual Basic 6.0 functionality.

What happens when I upgrade an application that contains Remote Data Control Technology?

It appears the controls are upgraded by the upgrade wizard; however, the new controls are read-only at run time. In this case, you will not be able to navigate between results. A better option is to replace the RDO technology with ADO technology in the Visual Basic 6.0 application before you upgrade it.

What are custom data access components?

Custom data access components are those components that encapsulate data access technologies such as ADO, DAO, or RDO inside a DLL or an OCX that your application uses. These components may have been developed internally in a specific language, or they may have been purchased from another company with or without the source code.

What upgrade alternatives do I have for applications that use custom data access components?

You can choose from two upgrade options:

• Upgrade your application and use a wrapper for the component.
• Upgrade the application and the component separately, and replace the old component with a new Visual Basic .NET based component.

If the application uses different technologies such as ADO, RDO, DAO and custom data access, what’s the best way to go?

When your application uses different technologies, you should consolidate all of the data access into a single technology before beginning the upgrade. Your best option in this case is to use ADO because it can be upgraded automatically by the upgrade wizard. This in turn, will reduce the number of manual changes you will need to make in the upgraded code.

As an alternative, you can choose to upgrade each technology separately. This requires that you create a new Visual Basic 6.0 project for each technology that your application uses. Each project must be upgraded separately. After all of the projects have been upgraded, you will have to integrate them into a single application in Visual Basic .NET.

How are VB 6.0 Data Reports converted to .NET ?

Crystal Reports is the standard reporting tool in Visual Basic.NET. One of its most important advantages is the ability to convert a Microsoft Data Report (.dsr file) to a Crystal Report (.rpt file) through a relatively easy automated process. When a Data Report is converted, an equivalent Crystal Report is generated. The resulting report has the same design and data access as the original report.

However, the Crystal Reports tool cannot convert Data Reports that contain a query that uses parameters to retrieve data, so the best option would be to manually re-implement the reports.

In cases where Crystal Reports can be used for automatic conversion, you will first need to upgrade all of the associated Visual Basic 6.0 projects, forms, and data access components to Visual Basic .NET. Next, you will need to upgrade the Data Reports to Crystal Reports. And finally, you will have to make some changes in the project to allow the upgraded code to work with the converted Crystal Reports.