Migration Process
Last updated
Last updated
The VBUC allows converting DataAccess related classes like the classic ADODB, Microsoft DAO, RDO or OracleInProc Activex components to .NET equivalents, or even keep them using the original components via COM interop.
In this post, we are not covering the migration to COM interop for those Activex components.
This solution uses a set of helper objects to provide equivalent behavior in .NET and to encapsulate the ADO.NET machinery required to handle a set of data, more specifically, for the RecordSet object, which is very powerful and flexible in Visual Basic 6 and does not have a direct equivalent in .NET. This approach reduces the manual changes effort to achieve functional equivalence.
The usage of System.Data.Common libraries provide the application with the ability to interact with different Database Manager Systems (such as SQL Server, Oracle, MS Access, etc) through its ADO.NET 2.0 compliant providers with just minimal configuration efforts.
More info is found at Classic ADO Conversion to ADO.NET
This optional feature allows the VBUC to convert RDO to plain ADO.NET by using the provider-specific System.Data.SqlClient libraries.
Remarks:
This approach converts RDO to plain ADO.NET, but it might require several manual changes to achieve functional equivalence.
Transformations to occurrences of MSRDC will also be applied when selecting this choice.
Do not mix Upgrade options in a single migration even if source components are different: such as ADODB and RDO in the same VB6 project.
Due to design in VBUC 8.2 and older, choose System.Data.Common and HelperClasses to migrate ADODB will cause conflicts if SqlClient is chosen for RDO.
If System.Data.Common + Helper is used for some classes and SqlClient for others, the generated code will be hard to modify in order to achieve functional equivalence.
Make sure to be consistent, and just pick either only the SqlClient or only the System.Data.Common + Helper classes options.
