Jump to content


Mobilize.Net Staff
  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by OlmanQuesada

  1. Hello Prasad,


    Sorry for the late response. You can use the Profiler tool that comes in VS.NEt to determine bottlenecks and performance issues.

    In regards with the RecordsetHelper, this is an enhanced .NET Dataset component that emulates the classic ADO recordset used in VB6.

    Performance issues may be related to the querie itself, infrastructure issues of the machine where either the .NET app or the DBMS are running. Also, there's a specific feature in the RecordsetHelper may affect the performance, so I'm going to elaborate deeper on this:

    In VB6, when a recordset is populated, the database schema for that sql operation is retrieved from the database, this is useful when the recordset data is modified (adding new rows for instance). To get the same behavior in NET, you need two database operations: 

    - get data. This is achieved by executing DbAdapter,Fill() to populate the DataSet (the RecordsetHelper is a dataset that extends the dataset functionality)

    - get schema. This is achieved by executing DbAdapter,FillSchema() method (used by the recordsethelper)

    This addicional database operation (getting the schema) may affect the performance:

    If the schema is not used for an operation you can deactivate it by setting ADORecordSetHelper.LoadSchema property to false. Being a static property, be careful to set it back to true after opening the ADORecordSetHelper.

    C# code snippet

    ADORecordSetHelper RcdSet = null;
    RcdSet = new ADORecordSetHelper("");
    RcdSet.CursorLocation = intUseClient;

    ADORecordSetHelper.LoadSchema = false;
    RcdSet.Open(strSQLStatement, m_conAdoConnection, intLockType);
    ADORecordSetHelper.LoadSchema = true;

    If possible, identify ADORecordsetHelpers opened for reading purposes only.
    For each of the previous identified ADORecordsetHelpers apply the suggested modification described above:
    Before the <RecordsetHelper>.Open) method call, set the LoadSchema flag to false, and then set it back to true.


    Please let me know if this help you out to solve the problem.



  2. Hi Nishant, We've been reviewing the issue and the code snippet. Can you provide us mofre details about the file where that code snippet is located. We look for that into our framework and the migrated code of you applicaiton but we were unable to find that piece of code. 


  3. Hi,

    The VB6 code needs to add the parameter to the parameter collection before accessing the value of the parameter otherwise an error at runtime is generated.

    The vb6 code does not indicate how the parameter at the index 0 of the collection is created, without that the followin line in the VB6 code will crash at runtime because there's no parameter at index 0.

    svrqAuthorise.Parameters(0) = mvlngEntityRefToMoveFrom

    When that code is converted to C#, a similiar situation happens, if the parameter is not created and added to the parameter collection a crash is generated. 

    In this case the creation of the parameter is not incuded in the VB6 code.

    The situation described here is not necesarrily an issue with the converted code but it could be related to a problem in the source code.

    To determine what is causing it's important to check when the parameter at index 0 is created and added to the parameter collection. 


  4. Hi Charlie,

    You can solve this situation by re-migrating the code by modifying the Migration Options to use Mobilize helper classes to deal with Default Properties and Late Binding Objects, as shown in the image below.


    C# does not support Default Properties, so statements like  cvctlAuditControl = "" in .NET will need to specify the property for the object in cvctlAuditControl to set with an empty string. The VBUC provides a mechanism to help on this: The Reflection Helper. This helper class contains a collection of .NET classes and their respective Default Property. 

    The following sample shows how it works:


    Private Sub Form_Load()

    foo Me.Text1
    foo Me.Label1

    End Sub

    Sub foo(ctl As Control)
        If Not ctl Is Nothing Then
            ctl = "my text"
        End If
    End Sub



            public void foo(ref Control ctl)
                if (ctl != null)
                    //UPGRADE_WARNING: (1068) ctl of type VB.Control is being forced to Scalar. More Information: https://www.mobilize.net/vbtonet/ewis/ewi1068
                    ReflectionHelper.SetPrimitiveValue(ctl, "my text");

    The Upgrade Warning 1068 indicates there's a situation, in this case caused due to a Default property in VB6. The ReflectionHelper.SetPrimitiveValue extract the datatype of the ctl object and then look for the associated Default Property (if any) to assign the "my text" value to that property.


  5. Hi Aldebaran,

    I recommend to run the migration again and running the pre-process step before 

    We would like you to run the migration again from scratch, making sure you have all the references right and you run the preprocess.  Please make sure the ADODB reference is resolved and make sure the output folder is empty before running the migration process: Go to the "Upgrade area", right click on the project and select "Preprocess Project" option, then, when the Preprocess ends, you can upgrade the code again.



  6. Hi Aldebaran,

    I created a single vb6 project with a class having a similar property definition as you indicates and it doesn't compile: The vb6 compiler doesn't like having two property methods Get and Let with parameters. Do you mind if share with me (via email) the file where Duty property is defined? Also, which version of the VBUC you're using.




  7. Hi Astrid,


    In regards with the first error in Windows 7, please follow the next steps:

    [Workarround Steps]

    1. Open a Windows command prompt with administrator privileges

    2. Go the Mobilize.Net VBUC folder, where the binary files are located.

    It is very possible this folder is: “C:\Program Files (x86)\Mobilize.Net Visual Basic Upgrade Companion\”

    3. Execute the following commands:

    Vbu.exe /regserver

    C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe ArtinSoft.VisualBasic.UpgradeExtensions.dll

    C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe VBUpgrade.Engine.dll

    C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe VBUpgrade.Utils.dll

    C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe ResxManager.dll

    C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe VBUpgrade.OcxStateGenerator.dll


    I'd like to review with you the Dot Net class issue.

    Would you be available for a remote session at this moment?

    If so, this is the zoom URL https://mobilize.zoom.us/j/383181282

    Otherwise, we can coordinate a session for Tuesday next week just let me now your availability.




  8. Hello Astrid,


    Are you migrating the code using Windows 10 or any other windows version?

    Please send us an screenshots of the Solution and Resolve Reference section of the VBUC.


    The issue may be caused because there's a missing reference in the VB6 code (DLL with CLSID 11C67C12-105A-4F42-A5C8-CB9070F2855A).





    Olman Q

  9. Hello,

    In screenshots 3 and 4, there are two issues that have to be solved manually.

    1. The first is related to MSComDlg objects. In vb6 there exist only one single dialog object with several functionalities: print dialog, color dialog, open file dialog, etc. In .Net there are specific dialog objects according to their functionality. For instance, there is a openfile dialog, print dialog, etc. The VBUC tool converts every MSComDlg object into their respective equivalences in .Net, so if you find a single MSComDlg object in your VB6 form, the upgraded form in .Net would have as many .Net dialog objects as functioanlities detected in the original application. However, for non upgraded library elements of the original MSComDlg , it will create a stub class called UpgradeStubs.AXMsComDlg_AXCommonDialog. This stub class may reference enums or types defined in the MSComDlg Activex component.

    To avoid the error in screen 3 there are two paths:

    b. Verify what are the nn-upgraded elements for the UpgradeStubs.AXMsComDlg_AXCommonDialog instance created in that form and replace them by .Net functionality.

    a. Include a reference to the MSComDlg object and then perform (a).

    2. In regards with the second issue (screenshot 4), the error is generated because rst that is declared as object and in runtime it's created as ADORecordsetHelper (implementation of a .Net DataSet) is being cast to msdatasrc.DataSource and that casting is incorrect because msdatasrc .DataSource is an unmanaged type while ADORecordsetHelper  is a .Net type.

    What is the datatype for cboTeileNr? I looks like it's an Activex object.





  10. Hello Dion,

    Do you have a firewall that may be blocking connections attempts? You can try by implementing the winsock error event to trap error messages.

    My suggestion given you're now in .Net, replace the winsock by System.Net.Sockets. The communication between .Net and Interop/Activex components my be not as smoothly as expected, so using a pure .Net component could be the best option.

    Some guides about .Net sockets:



  11. You can find inline documentation in the helper classes and you're also free to edit them. The recordset helper tries to infer the right command type, but when the basic clauses are not fulfilled it has to get the database schema to find if the recordset is populated by querying to a table name. Retrieving the schema has a very important impact on the performance, so in this case modifying the source code by using the exec keyword would help to reduce the performance.



  12. Hello,

    ADO.Net  does not provide that functionality as classic ADO or ADODB does, that’s why the VBUC generate a stub indicating that property is not supported. In order to achieve the same functionality will require changes in your migrated code.


    The VBUC converts classic ADO components (like the recordset) to ADO.Net components. In specific, the recordset is migrated to a helper class that inherits from the System.Data.Dataset object.

    This class includes methods/properties to emulate the behavior of the classic Recordset when possible, but there are some of them that cannot be emulated as ADO.Net does not provide any way to recreate them.

    For instance, using the <Recordset>.Properties(“Unique Table”) to indicate which table to be updated when the recordset is populated via a SQL JOIN statement.

    To get the functionality described above, you can use the <RecordsetHelper>, the Update/Insert/Select clauses must be provided in order to perform those operations. You can use the SQlInsertQuery, SQLUpdateQuery and SQLDeleteQuery properties of the RecordsetHelper class to indicate the Sql statement to use to execute SQL operations.

    As a workaround to this, Update/Insert/Delete SQL must be specified to perform those operations (here some info from Microsoft : https://docs.microsoft.com/en-us/aspnet/web-forms/overview/data-access/advanced-data-access-scenarios/updating-the-tableadapter-to-use-joins-cs)





  13. Old Visual Basic 6 applications interacting with Oracle databases may rely on the MSDAORA driver in the connection string to establish such communication when that code is converted to .NET, the Visual Basic Upgrade Companion (VBUC) will keep the same connection string and therefore be use the old MSDAORA driver. But, in .NET we can take advantage of the Oracle Data Provider (ODP.Net) technology developed by Oracle instead.

    The following VB6 code shows a database connection though the MSDAORA provider:

    Dim oConn As ADODB.Connection

    Set oConn = New ADODB.Connection

    oConn.ConnectionString = "Provider=MSDAORA.1;Password=" & sPassword & ";User ID = " & sUser & "; Data Source= " & sServer & ";Locales Identifier=1033"



    When this code is converted to .NET using the VBUC the code look like this:

    DbConnection oConn = UpgradeHelpers.DB.AdoFactoryManager.GetFactory().CreateConnection();

    oConn.ConnectionString = "Provider=MSDAORA.1;Password=" + sPassword + ";User ID = " + sUser + "; Data Source= " + sServer + ";Locales Identifier=1033";

    //UPGRADE_TODO: (7010) The connection string must be verified to fullfill the .NET data provider connection string requirements. More Information: https://www.mobilize.net/vbtonet/ewis/ewi7010


    Note: ADODB component is migrated to ADO.NET using System.Data.Common and helper classes.


    As you can see the migrated application is still using the MSDAORA provider.

    If your final goal is taking full advantage of the .NET technology, you may want to replace that provider for the ODP.Net developed by Oracle. In this case, you need to go to the Oracle Data Provider .NET download page (http://www.oracle.com/technetwork/topics/dotnet/index-085163.html) and choose the required version of this .NET component.

    After installing and configuring the ODP.NET component on your machine you will have to make some minor adjustments to the migrated code:

    1. Add the Oracle.DataAccess.Client factory

    Mobilize helper classes use a DVProviderFactory to create the right ADO.NET object according to the database connection provider in use:

    • OleDb providers will use the System.Data.OleDb namespace. This is valid for MS-Access files and any OleDb provider like the MSDAORA one.
    • ODBC providers will use the System.Data.ODBC namespace
    • SqlServer can use the System.Data.SqlClient namespace
    • Oracle providers for .NET will use Oracle.DataAccess.Client namespace that comes with the ODP.NET installer. If this assembly is not installed an exception will raise at runtime.


    To use the Oracle.DataAccess.Client, find the method Load DefaultFactorySettings that comes in the AdoFactoryManager class from the UpgradeHelpers.DB.Essentials helper project and uncomment-out the line:

    factorySection.Add("Oracle", new FactoryConfigurationElement("Oracle", "Oracle.DataAccess.Client", DatabaseType.Oracle, false));

    and comment-out this line:

    factorySection.Add("Oracle", new FactoryConfigurationElement("Oracle", "Oracle.DataAccess.Client", DatabaseType.Oracle, false));

     So, this method should looks like this:

             private static void LoadDefaultFactorySettings(Dictionary<string, FactoryConfigurationElement> factorySection)


                factorySection.Add("Access", new FactoryConfigurationElement("Access", "System.Data.OleDb", DatabaseType.Access, true));

                factorySection.Add("SQLServer", new FactoryConfigurationElement("SQLServer", "System.Data.SqlClient", DatabaseType.SQLServer, false));

                //New Changes

                factorySection.Add("Oracle", new FactoryConfigurationElement("Oracle", "Oracle.DataAccess.Client", DatabaseType.Oracle, false));

                //factorySection.Add("Oracle", new FactoryConfigurationElement("Oracle", "System.Data.OracleClient", DatabaseType.Oracle, false));

                factorySection.Add("ODBC", new FactoryConfigurationElement("ODBC", "System.Data.Odbc", DatabaseType.Access, false));



    With these changes, any ADO.NET object (DBCommands, DBConnections, etc) created using the UpgradeHelpers.DB.AdoFactoryManager.GetFactory() will be instantiated using the types defined in Oracle.DataAccess.Client namespace.


    2. Correct the Connection String

    As illustrated in the VB6 code above, the connection string is using an OLEDb provider (MSDAORA), so we need to change that string to send the parameters required by the ODP.NET provider:


    string conStr = "Data Source=(DESCRIPTION=(CID=GTU_APP)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST="+ sServer + ")(PORT="+ sPort + ")))(CONNECT_DATA=(SID="+ sSID + ")(SERVER=shared)))";

    conStr = conStr + ";" + "User Id=" + sUser + ";Password=" + sPassword;

    DbConnection oConn = UpgradeHelpers.DB.AdoFactoryManager.GetFactory().CreateConnection();

    oConn.ConnectionString = conStr;



    Basically, these are the only changes in your code to establish an Oracle DataBase connection using ODP.NET.


    happy migration!

    • Like 1
  14. Hi Devon,

    the cbo is a Activex Combobox, so it's not a .Net control. Because of that, the RowSource property cannot be assigned to a .Net class. At this point there are two alternatives:

    1. Change the AxDataCombo by a .Net control. In that case it would be compatible with other .Net classes/components. This have to be done in a manual fashion as currently the VBUC does not automatically convert that control to a .Net one.

    2. Migrate the vb6 code using ADODB via Com Interop (see attached file). By doing this, all classic adodb code willnot be converted to ADO.Net, so the cbo.RowSource and the rst object may be compatible.

    However, as you're converting your code to .Net my suggestion would be the option 1.







  15. Hi,

    Sorry for the misunderstanding.

    The VBUC requires all the references to all third party components as well as any library that is part of the VB6 project . The best way to validate that is compiling the vb6 code in the same machine where the VBUC tool is installed.

    You can get more information about how to prepare the code to be migrated by visiting our VBUC System Requirements page


    Please, verify the vb6 code in your machine compiles and them try converting that code.



  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Terms of Use