Legacy Data Access Modernization

The Visual Basic language eye-witnessed the rise and fall of several data access technologies. As the evolutionary path of the data access layers merged across vendors and platforms, the industry adopted these standards and eventually fulfilled the adaptation requirements to jump from standard to the other. ADO and ADO.NET are not the exception.

To be more specific, VB6 featured DAO, RDO and ADO to connect to the different data sources available at their respective moment in time. Therefore, the VBUC is able to handle all the previously mentioned data source technologies found in Visual Basic 6 and other related items such as visual controls used to access and modify data.

The legacy data access methodologies mentioned above share much of their functionality since they kept some sort of backwards compatibility among them. This explains the existence of all the three technologies in the latest versions of our customer’s VB6 applications.

During the massive technological shift that Microsoft created during the launch of the .NET platform, many technologies where forced to be ported into a considerably different counterpart. In the particular case of ADO, its predecessor ADO.NET boasts a performance-intensive architecture that uses XML and other new age technologies that were unforeseen for the VB6 applications running on the market nowadays.

Also, ADO.NET delivers a particular approach to deal with the different data providers and engines that centralizes the configuration efforts and produces vendor-free code. This particular functionality has allowed our customers to upgrade not only their applications but their database engines and providers as well without losing their valuable business logic on either side.

During our long and rewarding journey in the software migration industry, we have found that the decision to leap from ADO to ADO.NET gets clouded by increased difficulty to draw an analogy line between both technologies, and the comparison is even harder for RDO and for DAO since they were designed and implemented for older technologies.

Having said that, we decided to approach some of the ADO.NET particularities that might not be completely clear to the VB6 application owners:

• ADO.NET and data providers: The .NET framework incorporates different namespaces for each of the most common data providers (ODBC, OLDEDB, SLQclient and Oracle). This namespaces contain pre-configured logic to connect and communicate to the compatible database engines. Thankfully, the .NET framework 2.0 incorporates a new namespace (System.Data.Common) which enables the user source code to communicate to any database provider. The resulting code sports vendor-independent data access code that centralizes the configuration efforts into a single XML file.
• Legacy technologies and data providers: DAO, RDO and ADO where designed to communicate to different providers and database engines that where available in the same moment in time. The database engines that communicate to these legacy data access technologies can be used in .NET by means of the proprietary data providers incorporated in the .NET framework (listed above). However, this technique will create a combinatory amount of possible output source code and this is neither elegant nor maintainable.
• System.Data.Common, flexibility for everyone: As we mentioned earlier, the .NET framework version 2.0 incorporated the “System.Data.Common” namespace which enables the users to write vendor/provider independent code. The code that uses this namespace for data access can be configured using the “App.Config” file, just like the new breakthrough technologies from Microsoft such as WPF, WCF, WWF and others like the Microsoft application blocks, so the evolutionary path of the application will exhort to understand and use XML configuration files.

The Visual Basic Upgrade Companion is able to upgrade DAO, RDO and ADO plus the MSRDC and ADODC data controls. The possible combinations between source and target technologies are described in the following table:

For Example, the DAO data access technology is ported to .NET only through the System.Data.Common namespace.

The Visual Basic Upgrade Companion allows the user to select the data access technology to be used in the resulting code from the Upgrade options, the settings in the profile manager for data access are described here:

General Inquiries

Support Request