Debugging PowerBuilder Nested Report / Datawindow Parameters
I have an older "classic" PowerBuilder (forms) application that I inherited and support. I would like some way to debug what is going on with the database for it. Most of the datawindows use a stored procedure for data source but not all. I need a way to programatically, at the ancestor level (so generic, not specific to a certain type of datawindow object) at Retrieve time or shortly thereafter determine what the parameters are for the datawindow being retrieved and either log or display. I don't want to have to touch every window. I am using PFC.
For basic datawindows, I can get to, or at least suss out, this information in SQLPreview event, EXCEPT for nested reports. SQLPreview doesn't fire on nested reports. Is there a way to do this for nested reports (dwobjs embedded on another dwobject)? It seems as if even the PFC SQLSpy doesn't show the SQL executing for the nested reports so I'm assuming I'm out of luck but I would like a definitive and informed no if it is a no (with a reference). And I am using PowerBuilder 11.5. If this is fixable by upgrading I'd like to know that too.
I would like to do this without having to modify the other code other than at ancestor level (without touching every datawindow or window). Obviously if I touch all the child classes I can add in something to write its specific parameters somewhere and then display when needed. But I am trying to go for a generic approach for a generic debugging tool I can use on virtually any PB app (or any PFC app if I need to use PFC that is fine, all mine use it).
I know that I can determine what the NAMES and TYPES of the parameters are at run time by using dwchild.Describe("Datawind
Any PB gurus out there? I know this is a serious guru question and I will reward any helpful answer as much as I am allowed to by EE, including "outside of my box" suggestions that I may not have considered. ;-)
EDIT: Also I will add one more thing, I am using this on MS SQL Server 2008 R2, but we do not have the ability to run the SQL Profiler without going through a ton of SOX red tape and DBA assistance so that is usually too slow of a solution unless it is a serious problem and urgent. And we have some problems being able to run the PB IDE/debugger against production database. I can do that if it is critical, but I am interested in having something built into the app that is limited access and hidden that I don't have to cut through red tape to get working.
For basic datawindows, I can get to, or at least suss out, this information in SQLPreview event, EXCEPT for nested reports. SQLPreview doesn't fire on nested reports. Is there a way to do this for nested reports (dwobjs embedded on another dwobject)? It seems as if even the PFC SQLSpy doesn't show the SQL executing for the nested reports so I'm assuming I'm out of luck but I would like a definitive and informed no if it is a no (with a reference). And I am using PowerBuilder 11.5. If this is fixable by upgrading I'd like to know that too.
I would like to do this without having to modify the other code other than at ancestor level (without touching every datawindow or window). Obviously if I touch all the child classes I can add in something to write its specific parameters somewhere and then display when needed. But I am trying to go for a generic approach for a generic debugging tool I can use on virtually any PB app (or any PFC app if I need to use PFC that is fine, all mine use it).
I know that I can determine what the NAMES and TYPES of the parameters are at run time by using dwchild.Describe("Datawind
Any PB gurus out there? I know this is a serious guru question and I will reward any helpful answer as much as I am allowed to by EE, including "outside of my box" suggestions that I may not have considered. ;-)
EDIT: Also I will add one more thing, I am using this on MS SQL Server 2008 R2, but we do not have the ability to run the SQL Profiler without going through a ton of SOX red tape and DBA assistance so that is usually too slow of a solution unless it is a serious problem and urgent. And we have some problems being able to run the PB IDE/debugger against production database. I can do that if it is critical, but I am interested in having something built into the app that is limited access and hidden that I don't have to cut through red tape to get working.
ASKER
We have very limited rights on the production DB. This was part of the reason I'm trying to get as much info built into the application itself. DBAs can help, but then going through channels for that help generally takes more time than just manually reading through the code.
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
Thanks, I read about this some more and found that it can be programatically turned on and off in the app (say with a menu option) and redirected to a file chosen by the user so this could be an option available for certain levels of access. This is fantastic, it captures all SQL if you use "TRS" instead of "TRACE" (trace is way more verbose also if you need to know even more info for internal PB stuff I guess). Your tip got me looking for it in the right places.
http://infocenter.sybase.com/archive/index.jsp?topic=/com.sybase.help.pb_10.5.connpb/html/connpb/CJAJIACJ.htm
http://infocenter.sybase.com/archive/index.jsp?topic=/com.sybase.help.pb_10.5.connpb/html/connpb/CJAJIACJ.htm
I guess you have sa rights (or equiv) on the SQL? If so; I would make sure PB logon with a separate useraccount that I easily could monitor, then monitor it on sql manually not using profiler.
Outlined here:
http://msdn.microsoft.com/en-us/library/hh231524.aspx
Good luck :)