RE: How well does the converter convert ADO to ADO.NET ?
That's like asking "how well does a person convert ADO to ADO.NET?"
The answer depends how one defines "convert ADO to ADO.NET" and how precisely one is in implementing that definition.
gmStudio is a programmable software re-engineering tool. It works according to you its user defines and implement the conversion requirements.
In either case, the quality of the conversion definition is critical. However, there is a big difference: a person using the tool can implement the transformation very precisely and apply it very quickly (100s of thousands of lines per minute) whereas a person working manually cannot (a few lines per minute plus more risk of human error requiring tedious rework). If you have "a lot of code" to rewrite, or if you want to experiment with different ways of doing the rewrite, the speed and precision of tool-assisted conversion can be a game changer.
An example of how this is done for an RDO to SQLClient conversion is here: https://portal.greatmigrations.com/display/GMG/RDO+to+SQLClient+Sample. There is no need to convert DAO to ADO first -- the techniques from that sample can be extended and applied to any other API transformation, including DAO to ADO.NET.
There is also the option of using our ADODB emulation (MigrationSupport.DataLib), like we do for the FMStocks sample, as described here: https://portal.greatmigrations.com/display/GMG/FMStocks.
Please contact us if you have questions about rewriting your VB6/ASP code to meet specific data access coding standards and conventions.
Overview
Content Tools