VB Migration Partner supports the DataGrid control but not the DBGrid control. The reason is that the former is based on ADO binding and can be bound to any ADO-compliant data source, whereas the latter uses DAO binding and supports only the VB6 Data control as a valid data source.

For example, if the original VB6 application has a DataGrid control bound to an AdoDc data control, then VB Migration Partner converts the grid control to a VB6DataGrid control (a wrapper on the actual DataGrid ActiveX control) and the data control to a VB6AdoDc custom control defined in the CodeArchitects.VBLibrary. The VB6DataGrid control appears to be bound to the VB6AdoDc control, but in reality the data grid is bound to the ADO Recordset that the VB6AdoDc control opens behind the scenes. This mechanism works because the DataGrid ActiveX control can be bound to any ADO-compliant data source.

This trick can’t be used with the DBGrid control, though, because it can be bound only to the original VB6 Data control. Alas, the control support library neither does nor can include a COM wrapper for the VB6 Data control, because that control is a private class buried inside the VB6 runtime and can’t be extracted by means of the AxImp.exe tool.

To work around to this limitation you must edit the VB6 application to use ADO binding, and then replace the DBGrid and Data controls with the AdoDc control and the DataGrid control. Applying this fix is easy, because the DataGrid has exactly the same methods, properties, and events of the older DBGrid. After this fix, the VB6 application can be converted to VB.NET using the VB Migration Partner.