Forum Stats

  • 3,722,784 Users
  • 2,244,413 Discussions
  • 7,850,085 Comments

Discussions

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

oracle forms 12c remote debug windows to linux breakpoints not working

User_B1TRP
User_B1TRP Member Posts: 4 Blue Ribbon

I am trying to get the remote debugging working from my windows form builder to the remote form compiled and run on the linux server.

My problem is the breakpoints I create in form builder are ignored by the debugger. Although I can pause the running form and step through the code from that point onward and that functionality seems to work correctly.

I can't seem to find any documentation on how to create the breakpoints in the linux FMX file, I think I just need to add debug=yes to the frmcmp_batch command line. Are the breakpoints transferred over when the FMB file is copied to linux and recompiled?

compile command

 $FORMS_INSTANCE/bin/frmcmp_batch.sh module=$FILENAME.fmb module_type=form userid=$PROC_USERID batch=yes debug=yes

Best Answers

  • User_B1TRP
    User_B1TRP Member Posts: 4 Blue Ribbon
    Accepted Answer

    New Update: I just tried another test where I put the breakpoint in a "Program Unit" instead of the Button Pressed Trigger and that works. It is also surprisingly working without coding "DEBUG.SUSPEND" but rather just setting the breakpoint in the margin on the windows side, then save the FMB file, copy and recompile on linux. Not sure why this works, seems to be the location of the breakpoint that is the controlling factor.

  • Michael Ferrante-Oracle
    Michael Ferrante-Oracle Member Posts: 6,490 Employee
    Accepted Answer

    Great - glad you were able to get it working.

Answers

  • Michael Ferrante-Oracle
    Michael Ferrante-Oracle Member Posts: 6,490 Employee

    You cannot move the FMB from one machine to another and retain break points. You need to either create the break point on the machine where you plan to run or use the DEBUG package. Refer to the Builder help.

    In short, to add a break in your code that you plan to move to another machine, do something like this:

    DECLARE
    	rtn number;
    BEGIN
    	rtn := 1 + 1;
    	DEBUG.SUSPEND; -- Break here
    	IF rtn >= 2 THEN
    		MESSAGE ('That is a lot.');
    	ELSE
    		MESSAGE ('Need more.');
    	END IF;
    END;
    


  • User_B1TRP
    User_B1TRP Member Posts: 4 Blue Ribbon

    Thanks Michael. I understand now that the breakpoints are never saved in the FMB file and that they need to be added using a FormBuilder on each platform. Adding breakpoints, saving the FMB file on windows, moving it to linux and simply recompiling an FMX is not sufficient. I don't currently have a runable formBuilder on the linux platform, only on windows.

    I was able to successfully "break" using DEBUG.SUSPEND except that the FormsBuilder does not open the module containing DEBUG.SUSPEND but I see that it has stopped in the StackTrace. Is there another DEBUG command that tells formBuilder to go to right line of the code when it breaks?

  • Michael Ferrante-Oracle
    Michael Ferrante-Oracle Member Posts: 6,490 Employee

    When working with a remote server and one that is of a different platform than the Builder, you must do the following:

    .1. On the server, set allow_debug=true in the Web Configuration (e.g. formsweb.cfg)

    .2. In the module you want to debug, add DEBUG.SUSPEND to the area where you want a break point.

    .3. Save the code change and transfer that module (FMB, MMB) to the server. Do not close the module from your local (Windows) Builder.

    .4. On the server, generate the module using the command line compiler or the Builder.

    .5. Run the form (from anywhere), but include debug=yes in the URL (you can also add this to the Web Configuration if you prefer).

    .6. A dialog will be presented. It will include server information and a port number. This information will be used by the Builder, so if it is another user running the form and not the developer, the user should share those details with the developer.

    .7. In the Form Builder select Debug > Attach Debug from the menu.

    .8. In the dialog that appears, enter the information obtained in step 6 above then click on OK

    .9. Have the user click on OK and the form should start.

    The form and debugger should now be attached. It may be necessary to open the Debug Console manually. Debug > Debug Console

    When the break is reached, the code editor will open at the break point, assuming you did not exit the module.

  • User_B1TRP
    User_B1TRP Member Posts: 4 Blue Ribbon

    OK. I believe I have the instructions correct. But the symptom is still the code editor does not start until I step far enough that I reach code in the the PLL file that is attached to the form. It correctly steps through this library module and then drops back to the form trigger where it again does not follow the code. The Debug console does open automatically at DEBUG.SUSPEND. But the code editor does not open and follow with the stack trace. 

  • User_B1TRP
    User_B1TRP Member Posts: 4 Blue Ribbon
    Accepted Answer

    New Update: I just tried another test where I put the breakpoint in a "Program Unit" instead of the Button Pressed Trigger and that works. It is also surprisingly working without coding "DEBUG.SUSPEND" but rather just setting the breakpoint in the margin on the windows side, then save the FMB file, copy and recompile on linux. Not sure why this works, seems to be the location of the breakpoint that is the controlling factor.

  • Michael Ferrante-Oracle
    Michael Ferrante-Oracle Member Posts: 6,490 Employee
    Accepted Answer

    Great - glad you were able to get it working.

Sign In or Register to comment.