[SOLVED] dbg connect to the same path as the app

Author: knut.dybendahl@gmail.com (Knut)

I cannot be the only one with this issue - so either I'm missing something (which is entirely possible!) - or we all observe the problem and remain quiet; Here's my problem; From within my app I launch the debugger - and I can see / modify all variables etc etc. However, I don't seem to be able to inspect my current database path using the built in SQL Workbench. The workbench is there, but none of the path settings from my app is adhered to. I presume this is due to the fact that the debugger is really a separate app (exe) - in which case the threads to the db is difficult / impossible to connect to.... How does the rest of you solve the problem when you need to inspect data written back to the db - but not yet comitted (so other apps can see the data) - and no, we don't have a 'dirty-read' option available... :-( Knut

10 Comments

  1. 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


    Author: gianni (gianni.sandigliano@unifacesolutions.com)
  2. 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


    Author: ulrich-merkel (ulrichmerkel@web.de)
  3. 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. 


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  4. 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:

    ; Global Proc SQL_WB   returns string   params     string pDMLStatement : IN     string pPathString : IN     numeric nStatusBefore : IN   endparams   variables     string sResult, sReturn   endvariables   ; Remember $result   sResult = $result   ; Execute the SQL   sql/print pDMLStatement, pPathString   sReturn = $result   ; Reset $result and $status   $result = sResult   $status = sStatusBefore   ; Return result of SQL   return(sReturn) end;- SQL_WB

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

    "%%SQL_WB("select * from mytable","DEF",$status)%%%"

    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.

    "%%MYLIBRARY::SQL_WB(...)%%%"

    Hope this helps. Regards, Daniel


    Author: diseli (daniel.iseli@uniface.com)
  5. 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


    Author: Knut (knut.dybendahl@gmail.com)
  6. 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. Embarassed Sorry. Here's version 1.1: Wink

    ; Global Proc SQL_WB   returns string   params     string pDMLStatement : IN     string pPathString : IN     numeric nStatusBefore : IN   endparams   variables     string sResultBefore, sReturn     numeric nProcErrorBefore   endvariables   ; Remember $result and $procerror   sResultBefore = $result   nProcErrorBefore = $procerror   ; Execute the SQL   sql/print pDMLStatement, pPathString   if ($status >= 0)     sReturn = $result   else     sReturn = $concat("$procerrorcontext = %%^  ", %\ $replace($procerrorcontext, 1, "·;", "%%^  ", -1), %\ "%%^$dberror = ", $dberror)   endif   ; Reset $result, $procerror and $status   $result = sResultBefore   $procerror = nProcErrorBefore   $status = nStatusBefore   ; Return result of SQL   return(sReturn) end;- SQL_WB

    And as a little bonus I've added some "error handling". Laugh 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)


    Author: diseli (daniel.iseli@uniface.com)
  7. 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


    Author: Knut (knut.dybendahl@gmail.com)
  8. 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


    Author: diseli (daniel.iseli@uniface.com)
  9. EmbarassedEmbarassed Meeeehhhh - fingers too quick on the keyboard.... Awesome solution!! I owe you a beer next time I'm in Holland!!! Knut


    Author: Knut (knut.dybendahl@gmail.com)
  10. Knut said EmbarassedEmbarassed Meeeehhhh - fingers too quick on the keyboard.... Awesome solution!! I owe you a beer next time I'm in Holland!!! Knut

    Laugh 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. Wink Daniel


    Author: diseli (daniel.iseli@uniface.com)