Deepen ADO internal debugging

I have been doing a DataGrid link DBF database for a DATAGRID. DataGrid's data is ADO Recordset. An error occurred inside the ADO during operation of the DBF file. These errors are very difficult to debug. We know that ADO is operating through the OLE DB. These operations are usually converted to the SQL statement for the database. If we can know what the final SQL statement is, we have a great help to debug. The connection string of my link database is: "provider = microsoft.jet.oledb.4.0; data source = c: /; extended profment = dbase 5.0".

Finding the registry to get the file to implement the provider is: msjetoledb40.dll. Viewing this file with a Depends tool found that only 3 interfaces are exported to usually export. What is still in the interior still don't know. Find its symbol file, msjetoledb40.pdb. Just use the text tool to open it, it will find the shadow of the OLE DB COM excuse and function. Export his symbol with a pdbdump tool. It's more clear this time! Soon finding a symbol: setcommandtext @ cimpicommandtext @@ uagjabu_guid @@ pbg @ z, apparently cimpicommandtext is a class that implements the ICommandText interface. If you write Ole DB Provider, you will know that the second parameter of SetCommandText is saved with the mysterious SQL character. string. I want to see what is it!

Next, it is necessary to set up on the setcommandtext function, this breakpoint is not good. Seeing the function output of pdbdump is , RVA is not an offset address! Hurry up the Visual C Debug program. Open the MODUALS window, find the MSJETOLEDB40.DLL, look at its load address, then add offset. Set up breakpoints on this final address. Run the program and find anything! ! ! Faint !!! It seems that the RVA is a counterfeit. No time to study the source code of pdbdump. Can only be separately taken. We have symbols and want to find its memory address. Very simple, suddenly thinking of WINDEBUG. It has a command: x. Is to complete this work! You can only use WINDEBUG. Open the program in WINDEBUG. When MSJETOLEDB.DLL has been transferred to memory, run: x msjetoledb! * Setcommandtext *. One found is the address of the iCommandText interface setcommandtext. Note Be sure to put msjetoledb40.pdb to find it! Get this address, set the end point in the VC, and it is broken. Half of success! Open the stack window and see who calls setcommandtext, before the Call statement, there is definitely two parameters, where the first PUSH is the address of the SQL string. Suddenly discovered that the stack was wrong. Then, open the memory window, check the value of ESP, ESP, point to the return address, plus 4 is the address of the iCommandText implementation class, plus 4 is the first parameter, plus 4 is SQL string The address, the content of the address, my god! He finally came out!

Test it. When I modify the value in the DataGrid, the breakpoint will be activated immediately, and the string display is really the "Update" statement on the ADO reference book.