This content has been marked as final. Show 22 replies
Wow! You have a different approach to debugging than I do. :-)That was an example to demonstrate that using a timestamp is not slow like you thought. I usually use a minumum amount of debug outputs but because they go into a table and are queryable and unlimited I do have the option to use more (eg putting outputs within large loops), and I can filter out the excess if I want.
I like to write out just the minimum, and ONLY the values and checkpoints I want to see.
Your example of where ZDebug is handy is actually an example of the importance of putting some kind of debug output into a package. The method used to read the messages is largely irrelevant, although not having to rely on the existence of a forms app server would be a distinct advantage (what would you do if they were to move from forms to apex?).
Thanks for all the support, jwh. I gave the example trying to demonstrate how progress messages from both a form as well as a package can be viewed together in sequence. I am sure your debugging process would work as well in the same situation, if all the pieces were installed in the production environment.
(However, for that to happen at our multiple client sites, the package and table would need to go through multiple levels of testing and documentation, then release to the clients, then installation. That is more complexity than I want...)
Using zdebug, I like the convenience of having a Forms window displaying and managing the messages, and the ability to have the messages either popup when they are issued, or stored for later display.
thanks Steve Cosner for that tool.I will try it.
Plz help me
I am trying to use Zdebug form for display the error raised by the forms as well as database. But I am unable to to do. Even I follow all the steps as written in documentation might be I missing somthing. So can you give me your contact no So I can call you. Its very urgent so plz help me
Plz send me you contact no at email@example.com.
Mob :- 91 933 505 0509
Rajesh, in your email to me you wrote:
<p>I am looking for some kind of solution where I can capture/display any unhandled exception raised in the application (forms or database related) without touching 1200 forms and 1000 procedures for error trapping.
<p>Unfortunately, Zdebug cannot be applied to lots of forms magically. You have to copy a procedure (AA) and a button (B1.Debug) from the zdebug fmb into your form, and then you have to create messages (by calling the AA procedure) inside your form displaying information to help you find whatever problem you are having.
<p>And this is something you do usually while developing your form. It should not be added to production forms hoping that users can help you find the trouble. They would just be confused by the debugging steps and messages.
<p>If you are looking for a process to display database errors better from a form, you could use the Re: FRM-40735:Pre_Insert trigger raised unhandled exception ORA-20011 I have posted in this forum. However, in order for a form to use it, you must put the procedure in a PLL library, and then every form must be changed by adding a call to it in the form's form-level on-error trigger.
"it restricts text to 4000 instead of 255 characters and does not restrict the number of rows"
I think since 10gR2 this is not a restricion any more.
This might be interesting...
Thank you for Zdebug!