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.
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.
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.
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.
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.
With Data Environment, Visual Basic 6.0 developers can accomplish the following tasks:
When you use this automated migration tool to convert an application that uses Data Environment, the following changes are made:
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.
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.
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.
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.
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.
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.
You can choose from two upgrade options:
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.
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.
8834 N Capital of Texas Hwy, Ste 302
Austin, TX 78759
Call us: +1 (425) 609-8458
info@wearegap.com
