Meeeehhhh - fingers too quick on the keyboard.... Awesome solution!! I owe you a beer next time I'm in Holland!!! Knut

Knut said Meeeehhhh - fingers too quick on the keyboard.... Awesome solution!! I owe you a beer next time I'm in Holland!!! Knut

Once more, you are welcome. And should you ever be in the vicinity of Zurich (in Switzerland) then you also can buy me a pint of Guinness in one of the pubs here. Daniel

Hi Daniel, I just tried your clever solution - it doesn't seem to work here against 9.6.04 - I'll try it against 9.7 this week. Regards, Knut

Thanks Knut. And my "clever" solution does not work, because of a typo in the code - defined a variable called nStatusBefore and in the code used sStatusBefore. Sorry. Here's version 1.1:

And as a little bonus I've added some "error handling". And please don't just copy-and-paste the code. I've recognized that the editor is replacing the straight double quotes. So you need to correct this before you can use the code. Hope this helps. Regards, Daniel UPDATE (Oct 30, 2015): I've tweaked the code a bit more (now it also remembers $procerror)

Hi Daniel, Well, the code isn't throwing an error - I modified it to do a putmess after the SQL statement - yes, the content of $result is indeed dropped into the message frame of the debugger - but I cannot see it in the quickwatch - all I get back is PROCERR[]. But, at least I can get something sensible back to the message frame of the debugger!! Knut

Knut said Hi Daniel, Well, the code isn't throwing an error - I modified it to do a putmess after the SQL statement - yes, the content of $result is indeed dropped into the message frame of the debugger - but I cannot see it in the quickwatch - all I get back is PROCERR[]. But, at least I can get something sensible back to the message frame of the debugger!! Knut

Hi Knut, Thanks for the info. If you, however, don't see the result of the Global Proc in the Quick Watch then there's probably still a typo somewhere. PROCERR[] should only be returned if something went wrong. I'll get a similar return value when I use a variable in the code that is not defined (i.e. the typo I've mentioned above). Maybe it helps to enable Proc Tracing (Debugger Menu: View > Settings: Tab Tracing: Enable "Proc Tracing"). Once you run the Proc from the Quick Watch then you should see the executed in the Message Frame (or Log file) of the application. Or could also call the Proc from a test form and debug it from there. Hope this helps. Daniel

Hi Knut, my answer could be obvious but usually I have: - UDBG for data currently in memory or ready to be written to db but not yet committed from Uappl; I often add putmess and tracing when debugging server functionality - a separate client appl to analize data committed to db I never felt the need to have SQL workbench available into UDBG...but it could be useful for both novices & experts! :-) Take care not all databases enable to view data not yet committed in a db connection from another db connection... Gianni

Hi Knut, because 2 applications can not share the same database transaction, we have to provide a SQL option in our AUT (application under test): As the SQL workbench is nothing more than a SQL/PRINT with fields to enter the parameter values, you may (in a non-modal application) add a component with these fields. If you have a second monitor I recommend a "secondary" form. So at least whenever the structure editor is active, you can use this homebrewed SQL workbench. Greetings from Frankfurt, Uli

Unfortunately, that would not be an option for those of us doing client/server, where the UI has no idea as to the data path. That having been said, as I do stateless client/server, there isn't any point where the structure editor would kick in and there would be outstanding transactions anyway. I am fortunate to have a dirty read available on the database. I can see the original poster's problem however. 

Knut said I presume this is due to the fact that the debugger is really a separate app (exe)

Hi Knut, You have basically answered your own question here: the Debugger is in fact a separate application; and when you use SQL workbench in the Debugger then it will run in the context of the "Debugger app". Here's an "experimental" idea: create (e.g.) a global Proc that accepts a (SQL) string that is passed to sql/print and the result is then returned as string. You then can call the global Proc as part of a string substitution using (e.g.) the "Quick Watches" screen. Now you should have a way to inspect the data in the db in the context of the app you are debugging. For example:

And in the Debugger you enter the following as expression in the "Quick Watches" of the Debugger

And when you press Calculate then it (hopefully) will give you as result the return value of the specified SQL statement. Please be careful when adding the expression to the Watch List (because the global Proc will then be called every time you step through the code). And please do nothing "funky" in your global Proc that might have any influence on the code of the application you debug. In the above sample I try to reset $result and $status to their previous values so that the debugged Proc will work as expected. Update: In case the Global Proc is not found then you might need to add the library to the call; e.g.

Hope this helps. Regards, Daniel