This document describes the steps necessary to successfully configure the app.config file that is generated by VBUC during the migration of Visual Basic 6.0 data access technologies to ADO.NET using System.Data.Commons.
In .NET Framework 2.0, Microsoft incorporated the System.Data.Common namespace, which contains classes intended to be the base for the implementation of all data providers. This architectural decision allows application designers and programmers to use data provider-agnostic patterns on their data access layers.
VB6 offers several ways to access a database, all of them using COM libraries such as ADO, RDO and DAO. Many of the structures within these packages have their counterpart in the ADO.NET Common architecture, such as Connection and Command; in those cases most of their functionality is covered through our conversion approach.
The most common structure used to retrieve data from the database is the RecordSet object; in the case of ADO and DAO, and Resultset in RDO which are basically a collection of rows retrieved from the data source using a specific SQL command.
As counterpart in the .NET side, we have the DataSet object which also holds data retrieved from the database.
There are differences, though, between the DataSet in .NET and the RecordSet and Resultset.
The most important of them, from a functional equivalence standpoint, is its capability to “remember” the current position and make all data-related operations affect that record. The importance of this feature increases when these kind of object is passed (as parameter) through the different tiers and components of the application.
To accomplish the same functionality in C# .NET, Mobilize has developed Helper classes to handle all these operations. Internally, this class has the necessary infrastructure to support all database requests such as DataAdapters, using the System.Data.Common namespace.
The RDO and ADODB technologies have as well visual controls to interact with the Recordset and Resultset and to bind visual controls to its data. Those controls ADODC and MSRDC are supported as part of the Data access feature to give more functional equivalence to our clients.
Those controls are supported as well via helper implementations and some data binding patterns are supported and automatically upgraded.
The Helper classes are based on the specialization inheritance model, where the base class defines all common properties, methods, and the basic functionality. The derived classes overrides, adds new specific behavior to model the details. This design decision gives more functionality without breaking the natural ADO.NET architecture since the Recorset Helper classes are Datasets itself.
This structure is being use on the ADO, RDO, DAO common model as detailed on this diagram:
The App.config onfiguration file is an important component in the migration of VB6 legacy data access technologies to ADO.NET using System.Data.Commons. This file contains the list of the providers that the migrated application is capable to use and which are intended to be used as default. It also contains a definition of the columns which values are calculated or retrieved automatically from the database when an insert occurs, such as identities or values set by triggers.
This tag of the configuration file details the custom configuration section handlers used by the application; in the case of an application converted to ADO.NET using System.Data.Commons, it must be as follows:
This section specifies the connection strings that will be available for the migrated application.
This section details the providers that the migrated application may use and which one will be used as Default Provider.
The following data has to be filled out:
In the above example, MS SQL Server provider will be used since its attribute isdefault is set to true.
This section details the columns that are calculated by the database when an Insert is executed, such as identities or sequence values set by a trigger.
This section has the following data to be filled:
In the above example, an identity column was configured for table “CR_Customreport”.
The following is an example of a complete app.config file for a migrated application that can connect to:
Once the migrated code is generated by the tool, it is necessary to do the following steps to configure the app.config file:
Add the app.config file to the Visual Studio solution. To do this, right click on the project name in the Solution Explorer, Click on Add and then “Existing item”. By default, the app.config file is generated on the root folder of the conversion as shown below:
Open the app.config and change the configuration according to the database that the migrated application will be using. This includes:
Save the changes.
