This chapter contains the following topics:
Debugging is the method you use to determine the state of your program at any point of execution. Use debugging to help you solve problems and to test and confirm program execution.
Use a debugger to stop program execution so you can see the state of the program at a specific point. This enables you to view the values of input parameters, output parameters, and variables at the specified point. When program execution is stopped, you can review the code line-by-line to check such issues as flow of execution and data integrity.
You use the Visual C++ Debugger to debug C business functions.
You can use several strategies to make debugging faster and easier. Begin by observing the nature of the problem.
If the program is ending unexpectedly, the cause is likely an unhandled exception. An unhandled exception is a failure to handle memory correctly. It is an easy problem to track down if it is happening in the same place: simply set breakpoints at strategic points throughout the code and run the program until you find the problem.
If other objects are missing, termination is more abrupt. Remember to transfer all Media Object (also called Generic Text) objects correctly. If an application has a Row exit to an application that does not exist, an unhandled exception in the program occurs immediately.
Termination of the program is more abrupt and less helpful when other kinds of objects are missing. You must review all of the pieces of the application to verify that they are all present and correctly built. A common error is to overlook media objects. If you cannot enter the program at all, a missing object is most likely the problem.
Ensure that the program is terminating in the same place. If the program is failing to restore memory after its use, the program might eventually have insufficient memory to run. If so, you must reboot the workstation to restore memory.
Incorrect program output typically indicates a flaw within the logic of the code. To help find the error:
Set a breakpoint in the code prior to the point where the bad output is produced.
Step through the ER line by line, while monitoring the values of relevant ER variables.
At some point, a variable will probably take on an erroneous value that subsequently produces incorrect output.
If that point occurs before your breakpoint, set another breakpoint earlier in the code and restart the application.
Continue this process until you find the statement that is causing the wrong value to be assigned to the variable.
Spend some time thinking about where the source of the problem might be. If you don't know which ER event is causing an error, try to isolate it. For example, you might be able to temporarily disable the ER one event at a time to see if the error still happens. You can try to repeat the processing of a single event by doing unnatural actions in the GUI, like toggling up and down between grid rows to force the execution of the Row Is Exited event. There are no predefined debugging strategies that will work in any given situation. Be creative and be persistent, until you narrow down the problem to its source.
You can output to a file a log of SQL statements and events by changing the line in the jde.ini file under [DEBUG] from Output = NONE to Output = FILE, as in the following sample. This is a useful debugging tool when you have narrowed a problem to a specific issue involving the JDEDB APIs.
[DEBUG] TAMMULTIUSERON=0 Output=FILE ServerLog=0 LEVEL=BSFN,EVENTS DebugFile=c:\jdedebug.log JobFile=c:\jde.log Frequency=10000 RepTrace=0
You can set breakpoints and examine the code.
This section provides an overview of the Microsoft Visual C++ debugger and describes how to:
Debug business functions attached to interactive applications.
Use SQL log tracing.
Use debug tracing.
You can use Microsoft Visual C++ to debug business functions that are written in C. You can debug business functions that are attached to interactive applications or to batch applications. The business function must be configured to run locally.
If you are debugging ER for business functions and C business functions, you can use the JD Edwards EnterpriseOne debugger and the Visual C++ debugger together. Follow the process until you log into JD Edwards EnterpriseOne. At that point, follow the steps for the JD Edwards EnterpriseOne debugger. Program execution stops if C code is accessed. You can then use Visual C++ to continue debugging. This method is useful if you are trying to locate a problem and are not sure whether the problem is in a C business function or in the application that calls the business function.
You must use the Microsoft Visual C++ Debugger to debug business functions that were written with the Event Rules scripting language and then interpreted as C code, or that were originally written in C . You can run the entire JD Edwards EnterpriseOne system through the Visual C++ debugger (that is, you can start the activeConsole.exe or JD Edwards Solution Explorer file from within the Visual C++ Debugger). This enables you to step out of the tool application code into the business functions that are called in the ER.
You can use the debugger to debug a C program and interactively stop and start it as needed. During debugging, you can check specific values of variables and parameters to determine whether a program is running correctly. You can also step through the code to see what code is actually being executed.
The debug commands are listed in the Debug menu. You can customize the tool bar to contain debug buttons, which you can use instead of the menu.
The Visual C++ has many features in the Debug menu. The Visual C++ debugger helps you efficiently solve real-world problems.
You can run a program using the Go command from the Debug menu. The program runs until completion unless you set up breakpoints.
The Step command is available on the Debug menu and executes the current line of code. When the line of code has been executed, the yellow arrow cursor appears on the next line of code to be executed.
You can access the Step Into command from the Debug menu. Use this command when the current line of code contains a function call. The debugger steps into the function so that it can be debugged line by line. When the function is complete, the debugger returns to the next line of code after the function call in the calling routine. If the source code of the function to be stepped into does not exist on the workstation, the debugger skips over the line of code as though the Step command was used.
Stepping into a standard C function takes you into the function, which you might not want to do. If so, use the Step Over command to skip those functions.
You use breakpoints to run the program until it reaches a certain line of code. If a breakpoint is set, the Go command runs the program until it encounters that line of code.
You can set a breakpoint by placing the cursor anywhere on the line of code. When you select Debug, Breakpoints, a red octagon appears to the left of the line of code where the breakpoint is set. When the program is run, all lines of code up to the breakpoint are executed. To continue execution after the breakpoint, you can use Step, Step Into, or Go .
You can use Watch to inspect what values variables are set to. To use Watch, click the item that you want to watch and drag it to the Watch window.
All local variables and parameters to a function are listed with their data types and values in the Locals window. You can modify the values of all items in the Locals window during debugging. This is useful if you are debugging infinite loops.
Visual C++ has two tracing utilities that you might find valuable: SQL Log Tracing and debug tracing. You can use SQL Log Tracing to help you determine the exact SQL statement that is generated and sent to the database.
To debug a business function attached to an interactive application:
Close the application.
The application must be closed to debug in Visual C++.
Open Visual C++ and verify that all work spaces have been closed.
Select File, Open.
Select List Files of Type to accept executables (.exe).
Select activConsole.exe on path \b9\System\bin32 and click the OK button.
The system creates a project work space.
Select Project, Settings.
Click the Debug tab.
In the Category list, select Additional DLLs.
Click the Browse button to select the CALLBSFN.dll (which must be built in debug mode) or other appropriate DLL on path \b9\path\bin32, where path varies, depending on the path code.
Click the OK button.
Select the .h and .c files for the source that you want to debug from and then select File, Open.
To set breakpoints in the code, select Edit, Breakpoints.
If this message appears, click the OK button:
cannot open *.pdb
If a message appears notifying you that breakpoints have been moved to the next valid lines, a source code and object mismatch might exist, and you might need to rebuild the business function.
Select Build, Start Debug, Go.
The JD Edwards EnterpriseOne sign-in window appears.
Sign in to the application as you normally would sign in.
Run the application.
When the application reaches the business function in debug, the debugger opens or displays the C code in Visual C so that you can step through it.
This task is useful only for ODBC connections.
To use SQL Log tracing:
From the Control Panel on the workstation, select Administrative Tools, and then Data Sources (ODBC).
Select the 32 bit ODBC driver, and then click the Tracing tab.
Specify when you want the system to trace.
Specify the log output path in the Log file Path.
To use debug tracing:
In the jde.ini file under [DEBUG], set Output=FILE.
Change the value for Level= to suit the specific debugging needs.
Possible values for Level are contained in the comment line following the Level= line. Any combination is acceptable. Use commas to separate values.