Q: I observe that the tool-generated C# code ADODB.cs contains only skeletal code and methods. Is this intentional?
A: Yes that is expected and intentional at this point in your project. This is described in the methodology document I sent you.
As we have no way of knowing your organizations .NET development standards, we begin with a direct translation out of the box. The "direct" translations are only a starting point. Typically, you will use them for assessment and planning purposes only and then modify the translation rules to produce codes that use .NET types according to your standards. That way, you end up with a more maintainable app that follows your technical standards.
For example, gmStudio can be configured to use other approaches to data access:
- rewriting the code to follow some use of an in-house data-access API standard you have
- rewriting the code to use System.Data directly (see the RDO sample on our site and this: http://www.greatmigrations.com/pubs/ComponentReplacement.pdf)
- rewriting the code to use a .NET emulation of ADODB (this is compatible with what you have, but still requires some work)
- rewriting the code to use COM interop to ADODB (this is compatible with what you have, but still requires some work)
We freely distribute a small version of DataLib with the samples. It is in MigrationSupport.dll. An example of how to use the DataLib can be found in the FMStocks sample.
Let me know if you would like to license the source code for the small DataLib or purchase professional services to assist you with customizing the re-engineering work.