This chapter contains the following topics:
Use this section as a general guide for basic troubleshooting techniques on the Oracle JD Edwards EnterpriseOne workstation. To troubleshoot problems, you will need a thorough understanding of the interactive error messages, Oracle's EnterpriseOne Work Center, logging process, and associated log files.
This section provides solutions to these problems that you might encounter on the workstation:
You might encounter these issues when running a batch process:
Report displays no data.
It displays only the report headers and the text No Data Selected.
Batch process displays errors on the report.
Batch process gives unexpected data on the report.
You might encounter these environment issues:
Works when the batch process or business function runs locally but not when it runs on the enterprise server.
For store-and-forward operation, data entered to the local database is not moved to the server as expected.
Tables are missing.
You might encounter these problems with the data source setup:
Unable to connect to the enterprise server environment.
Data is displayed incorrectly on the interactive form or batch report.
When you encounter an error, right-click the error message in the error message window and select Detail to provide additional information about the error. This information provides the source file and the source line that caused the error. If you try to set up an Item/Branch record in P41026 with an invalid item number, you will receive error number 0267 (Item Number Invalid).
When indicating the source file that generated the error, the system provides the entire path of the source location. In this example, the source file is c:\E900\MSTR900\X4101.C, and business function X4101 created the error. The other pieces of the path are directory names. The important information in this example is the file with the .C extension (X4101.C).
If the detail for the error includes the name of the source file, you can identify the process that the file performs to determine what might occur to cause an error. For example, the name of the source file might include system code that indicates the process performed by the file. The process might attempt to run in a module that is not fully functional. The cause of the error might be a constant set to perform a function that is currently unavailable. When you disable the constant, you avoid the error.
Note:
If you see a source file description that begins with c:\E900\SYSTEM, the error did not occur through a business function. Possibly, the error occurred through an event rule or the tool, while automatically triggering a data dictionary edit.Look for conditional statements that determine whether to activate the error message. Look for table names to determine whether the program attempts to retrieve data. Look for other programs that the program might call. Also, read the programmer comments that are included in the source, which might provide a literal explanation for why the code issues an error.
Also look at the data item that caused the error. The data item represents a control on the form. If you get a Blanks Invalid error without an indication of what field you left blank, look at the data item in this error detail box to see which control triggered the error. The field that contains the error might be a hidden field. For example, if you process a transaction that requires a supplier number determined by an Item/Branch combination decided by JD Edwards EnterpriseOne (not by a value that you define on the form) but no supplier number exists for the Item/Branch combination, the software returns the Blanks Invalid error. The field for supplier number does not appear on the form, so the cause of the error is not readily apparent. The data item might alert you to the hidden field and help you resolve the error.
These error messages are maintained in the data dictionary and are intentionally set to inform the user of a problem. The error message might indicate that the setup is incorrect or that the user is attempting an invalid action. Examples of these kinds of error messages include Record Invalid and Blanks Invalid. Some generic errors lack applicable descriptions; techniques for troubleshooting these errors are discussed in this chapter.
Some error messages are too generic to immediately explain an error. Examples are Null Pointer and File Can Not Be Accessed. The full descriptions of these error messages do not provide much information as to how to resolve the problem.
To troubleshoot generic errors, retrace the exact steps that led to the original error. The goal is to reproduce the error. If you cannot duplicate an error condition, then the application is accessing different lines of code than it did when the error occurred. Also look at the information in the error detail box, such as the source file, the source line, and the data item.
Memory violations occur when you encounter memory leaks in an application. A memory leak is a bug that prevents a program from freeing memory that the program no longer needs. The program continues to consume more memory until no memory remains, and the program crashes. JD Edwards EnterpriseOne applications set aside memory while they run. When the application no longer needs that memory, the application should free the memory for other applications to use. When an application does not properly free memory or when an application attempts to use invalid memory, you receive a memory violation.
Use these techniques to troubleshoot these errors:
Look at the jdedebug.log to find information about the processing that occurred at the time of the error, such as programs called and tables accessed.
Follow the exact steps that led to the error to reproduce the memory violation.
If you cannot duplicate the violation, then the application is accessing different lines of code than it did when the violation occurred. Also look at the information in the error detail box, such as the source file, the source line, and the data item. For UBEs, if the UBE uses a business function that causes memory violations, the UBE will simply stop. In this case, the ube.log is the only way to find out what failed.
The two error messages that follow indicate that an attempt to add a new record to the database failed. The first message indicates that an add within a fix/inspect form failed. The second message indicates that an add within a grid failed. If you receive these errors, you could be attempting to add a duplicate record.
Attempt to add form record failed.
Attempt to add grid record failed.
The jde.log is a helpful reference when these errors occur. In general, it includes detailed information about the table into which the user attempted to add a duplicate record.
When submitting batch processes to a server, you might receive an error telling you that a communication failure has occurred.
When you submit a batch job to a server, you are first asked whether you would like to install the specifications. If the job is submitted successfully, JD Edwards EnterpriseOne reverts to the initial form.
This section provides an overview of production workstation troubleshooting and discusses how to:
Perform preliminary troubleshooting.
Troubleshoot interactive application problems.
Troubleshoot batch processes resulting in no data.
Troubleshoot batch processes displaying errors on the report.
Troubleshoot batch processes displaying unexpected data on the report.
Troubleshoot batch processes ending in an error when submitted on the server.
Troubleshoot local data-availability problems.
Troubleshoot .DLL problems on a production workstation.
Troubleshoot data source setup problems.
The troubleshooting procedures that you use for a workstation depend on whether the workstation is a production or development machine. Production machines contain only JD Edwards EnterpriseOne applications, so the scope of problems that can occur is limited. In addition to containing prebuilt applications, development machines are equipped with JD Edwards EnterpriseOne and third-party tools. These tools enable developers to create, modify, compile, generate, and troubleshoot JD Edwards EnterpriseOne applications.
As a system administrator, you can perform preliminary troubleshooting on the production workstation to verify the nature of the problem. You will also want to isolate problems to a user's particular workstation and environment.
In general, when you are running an interactive application, the system displays errors at the bottom of a form. The system highlights the fields with errors in red. You can select Details on an error message to see information about where the error was set. For example, if the error resulted from within a business function, the system displays the business function and line number where the error was set.
If the errors cannot be resolved through the error messages that are received in the application, check the error messages in the log files for additional information.
If an application has stopped running, you might need to create or retrieve a new set of specifications for that application. You can overwrite a single application by building a partial package and deploying that package.
A user might encounter several problems when attempting to run a batch process. For example, the output might display only the report headings or it might print a message such as "No Data Selected." If the result of a batch process is no data, several factors could be causing the problem.
Some batch processes will give error messages directly on the report. These messages should include both the short description and error message number. You can view the full description of the error by opening the message in Data Dictionary Design.
If errors are received when you are attempting to sign in to a JD Edwards EnterpriseOne environment, a possible cause is an incorrect data source setup on the workstation. Some indications of incorrect setup are:
A form continues to request a user ID, a password, and a data source even after valid ones are entered.
Data is displayed incorrectly on an interactive application.
Messages in the logs refer to problems connecting to data sources or concerning incorrect passwords.
If you find that you cannot perform a force checkout on a PC running a standalone installation of JD Edwards EnterpriseOne, it is because the software cannot determine the system name for a standalone installation.
The solution is to disable the DNS name in Microsoft Windows.
If the workstation is running a report against any enterprise server database, such as Oracle, SQL Server, or DB2 for IBM i, you need to check the database to see whether the SQL statement can find data in the tables. With the help of a database administrator, you can run the same SQL statement against the server database to verify that the expected data exists in the tables.
As an alternative or in addition to these procedures, you can also use the Universal Table Browser to verify table structure and data availability.
If you do not find any data in the tables for the environment against which you are running, then the SQL statement might be incorrect or the table is empty. Check the data selection and processing options, and verify that they are selecting data that is in the tables. If you do not have data in the tables to match what you are searching, then you will get unexpected results or no data on the report.
For example, if you leave the processing options blank (even though that may be a valid entry for a JD Edwards EnterpriseOne batch process), the process might be searching for blank values or for all values. If the data selection is selecting on a company that does not have any records, then the report batch process does not find any records.
Most printing errors are written to the batch process log. However, some errors might appear on reports or be visible in another form. For example, the report prints an error message, prints in the wrong font, or prints landscape instead of portrait.
These printing problems can occur:
The batch application produces error messages on the report, for example, Invalid Company Number.
The report batch process displays the wrong font on the report.
Check the report properties of the version that you just ran. Also, for the section that is not printing the correct font, check the section properties for the font. If the font is correct, then try printing to a different printer. Otherwise, try using another workstation to see whether the font that is being sent to the printer is not interpreted correctly.
The report batch process prints portrait instead of landscape or landscape instead of portrait.
Check the report properties of the version that you just ran and verify that the properties are correct.
See Also:
To perform preliminary troubleshooting:
Determine whether you can consistently duplicate the problem.
If you can duplicate the problem, restart the current application.
If the error recurs, restart JD Edwards EnterpriseOne.
If the error recurs, reboot the workstation.
These steps clear any memory or caching problems with the workstation.
To troubleshoot interactive application problems:
Select one of these to see the text of the message:
Display Errors from the Help menu selection.
Display button on the toolbar.
F8.
To see the full description of an error message, right-click and select Full Description.
The system displays a full glossary of the error and includes information for resolving the issue.
This task provides a solution to previously discussed problems.
To troubleshoot batch processes resulting in no data:
Verify that the data selection on the batch process is appropriate and that data should result.
Data selection on an item that has no data, such as an inactive company, or an incorrect value will result in a batch process with no data.
Check the Work Center to see whether the batch process resulted in an error.
Most error messages are not printed on the report but are sent as an email message to the user who submitted the report.
These messages will give the user an example of why the batch process ended without producing the desired results. For example, when the system runs a GL post that ends in error, the report will print only the report headings. All error messages are sent to the Work Center.
Upon quitting the Work Center, the user receives error messages and a glossary description that indicate why the batch process resulted in no data. Some error messages include hot links that link the user directly to the appropriate interactive application to correct the error.
If checking the data selection and correcting any errors does not resolve the issue, activate the applicable logs and continue with these steps.
Run the batch process and locate the batch process log for the report that you ran.
JD Edwards EnterpriseOne names this log with these conventions:
report name_version_other identifiers.log
This log is located in the local directory under \E900\PrintQueue. If you ran report R04431, it would appear in the local directory, E900\PrintQueue, like this:
R04431_XJDE0001_D960823_T104512.log
View the log file using the JD Edwards EnterpriseOne Log Viewer or an ASCII editor such as Notepad or Wordpad.
Inspect the log for errors or failures of any kind. Also examine the SQL statements that were created by the batch process and verify that they should result in data on the report. The batch process log is the main source for debugging batch processes. However, you can look in the jde.log and jdedebug.log for errors or failures of any kind.
Verify that data exists in the tables for the database that you are accessing.
Use the Universal Table Browser tool to view the database table.
Access Error Messages from the Data Dictionary Design menu (GH951).
To troubleshoot batch processes displaying errors on the report:
On Error Messages, complete the Glossary Group field.
Complete these optional fields:
Language
Alpha Description
On the grid, enter values in the Data Item field and click Find to narrow the search to the particular error code.
For example, enter 0002 to search for the data item that is associated with the Record Invalid error condition.
To see an extended description of the error, select Glossary from the Row menu.
To troubleshoot batch processes displaying unexpected data on the report:
Verify that the data selection on the batch process is correct and should result in the data output that is expected.
Activate the batch process log and run the report.
Examine the report process flow and SQL statements to see why the data output on the report is selected.
The default processing location for batch jobs is the server. If a job gives incorrect results or ends in error when run on the server, the problem could lie with the batch process or with the server. When you troubleshoot batch processes ending in an error when submitted on the server
Rerun the report, but override the location to run on the workstation rather than the server.
You should be aware that if this is a very large report, the processing may take a significant amount of time. You may want to select less material to speed up the processing time.
Verify whether the outcome is the same as when the report was run on the server. If so, use the other troubleshooting procedures for batch processing to resolve the issue.
Inspect the local database at \E900\pathcode\data\JDELocal_PD900.mdf to verify that data exists in the tables that the batch application is accessing.
To troubleshoot local data-availability problems:
To find the calling SQL statement, open the batch process log.
JD Edwards EnterpriseOne names this log using these conventions: report name_version_other identifiers.log. This log is located in the local directory, \E900\PrintQueue.
Highlight the SQL statement, right-click, and copy the contents to the clipboard.
To view data in the local database, open the Universal Table Browser (UTB) and retrieve the table that the batch application is accessing from the local data source.
Use the information that you copied from the SQL statement to query the table in UTB.
If this action causes the expected records to be found, the data that you specified in the data selection matches the SQL statement, which means that data selection is not the cause of the problem.
Problems with workstation .DLL files are indicated if you receive an error message such as this:
CALLBSFN.DLL Load Lib failed
Such a message might indicate that the object does not exist on the workstation. Use a tool such as Explorer to verify whether the file exists. You can find consolidated .DLLs in the \E900\path code\bin32 directory.
If the .DLL does not exist on the workstation or if it exists but you continue to get the error even after restarting JD Edwards EnterpriseOne, you can get the correct parent .DLL by reinstalling JD Edwards EnterpriseOne on the workstation from the deployment server. Another option is to copy the parent .DLL from the deployment server package location or another functioning workstation. This option will be successful if the business functions that are built into the parent .DLL are the same on the workstation that you are copying to as they are on the one that you are copying from. Use caution when copying .DLLs. A workstation installation is the preferred method.
To troubleshoot data source setup problems:
From the Control Panel, verify that the ODBC settings are correctly defined and that the data source exists.
The proper settings vary by data source.
If other users will sign in to the same workstation, verify that the data sources are set up as system data sources rather than user data sources.
Data sources that are set up as user data sources must be set up for each user who is accessing JD Edwards EnterpriseOne on the workstation.
This section provides an overview of development workstation troubleshooting and discusses how to:
Troubleshoot .DLL problems on a development workstation.
Troubleshoot event rule problems.
Troubleshoot business function problems.
The troubleshooting procedures that you use on a workstation depend on whether the workstation is a production or development machine. Production machines contain only JD Edwards EnterpriseOne applications, so the scope of the problems that can occur is limited. In addition to containing prebuilt JD Edwards EnterpriseOne applications, development machines are equipped with JD Edwards EnterpriseOne and third-party tools. These tools enable developers to create, modify, compile, generate, and troubleshoot JD Edwards EnterpriseOne applications.
You can perform troubleshooting procedures to isolate and resolve a problem with a JD Edwards EnterpriseOne development workstation.
Problems with workstation .DLL files are indicated if you receive an error message such as this:
CALLBSFN.DLL Load Lib failed
Such a message might indicate that the object does not exist on the workstation. Use a tool such as Explorer to verify whether the file exists. You can find consolidated .DLLs in the directory E900\path code\bin32 and E900\system\bin32.
If the .DLL does not exist on the workstation or if it does exist but you continue to get the error even after restarting JD Edwards EnterpriseOne, the workstation has a problem with the build of one or more consolidated .DLLs. You can rebuild libraries or .DLLs using the BusBuild application from Microsoft Windows Explorer. The path to busbuild.exe is E900\system\bin32\busbuild.exe.
Use this procedure if you are receiving the error on a specific business function that cannot be found in the parent .DLL.
To troubleshoot .DLL problems on a development workstation:
Verify that the correct parent .DLL for the business function that is being run is referenced when you receive the error.
If the wrong parent .DLL is referenced, select Synchronize JDEBLC from the Tools menu within BusBuild to correctly synchronize the parent .DLLs.
Attempt to rebuild the business function from the BusBuild.exe.
The rebuild should include the business function in the parent .DLL.
To verify which business functions are part of a parent .DLL, select Dumpbin from the Tools menu within Busbuild.
This option lists all of the business functions that are included in the parent .DLL.
When you encounter problems with event rules on an interactive or batch application, several tools are available to help resolve the problem.
Review the event rules that are attached to the application or batch process for obvious problems such as disconnected assignments or incorrect parameters that were passed to business functions.
When the system generates the application, a compile error log is generated, which documents errors in the event rules.
Review this log for errors within the Event Rules.
The Debug Application within JD Edwards EnterpriseOne enables you to debug the event rules for an application or batch process.
You might be having business function problems if you are getting unexpected results or getting a .DLL error when you run a business function.
Microsoft Visual C++ enables you to debug a business function. You can use this tool to step through the logic and inspect variables, which often helps you detect the error.
This section provides an overview of the workstation log files and discusses how to:
View log files.
Set up the workstation jde.log.
Set up the workstation jdedebug.log.
Set up the batch process log.
Troubleshoot with the compile error log.
Troubleshoot with jdecpy.log.
Troubleshoot with the sql.log.
Activate sql.log.
Troubleshoot ODBC problems using sql.log.
Troubleshoot with the jdeinst.log.
You should be familiar with the various logs that are used to troubleshoot problems on the workstation. By using these logs and the procedures that are outlined in this chapter, you can troubleshoot problems with interactive applications, batch applications, or business functions running locally on the JD Edwards EnterpriseOne workstation. Determine whether you can duplicate the problem consistently or whether it is intermittent.
Do not leave the debugging logs active when the logs are not in use. The logs consume disk and processor resources, and therefore affect performance.
If you do not use data replication in the configuration, ignore error messages that refer to these tables in the jde.log and jdedebug.log:
F98DRPUB
F98DRENV
F98DRSUB
F98DRLOG
F98DRPCN
Each JD Edwards EnterpriseOne workstation uses global tables (glbltbl.xdb and glbltbl.ddb) to write disk cache files containing internal session-specific and workstation-specific information. For example, information about data dictionary tables and business views is cached. By maintaining a history of this cached session information, individual workstations will improve runtime performance based on their usage.
If you are doing application development, you might need to delete the global tables to see the results of the changes. This is because the system looks first to the disk cache to read certain table information. The information that is contained in the disk cache might not be synchronized with the current development. You cannot edit the contents of the disk cache.
We recommend that normal startup of JD Edwards EnterpriseOne in a production environment not include the deletion of these global tables. These files should be deleted only as a troubleshooting technique or a development aid.
If the global table files do not exist when JD Edwards EnterpriseOne is started, they will be created. If they do exist, they will be appended, not overwritten. The files are located in the E900/pathcode/spec directory.
In general, on JD Edwards EnterpriseOne workstations, logs are classified in these categories:
Logic processing.
Batch processing.
Application development (compiling and generating).
Object Management Workbench transactions.
You use two major log file sources for troubleshooting processing faults on the workstation:
This log displays fatal errors. Jde.log can track any fault that might occur within JD Edwards EnterpriseOne.
jdedebug.log (JDEDEBUG on IBM i)
This log tracks API calls and SQL statements as well as other messages. You can use this file to determine the point in time when normal processing stopped. The system does not use jdedebug.log to track errors. Instead, this log is used to track the timing of JD Edwards EnterpriseOne processes.
For JD Edwards EnterpriseOne workstations in application development environments, you can use these logs to identify faults in processing that are related to compiling and generating applications and business functions:
The compile_error.log contains compile errors for event rules. You can use this log to view event rules that might not properly compile and run. These include Named Event Rules, Table Event Rules, and event rules that are embedded in applications.
This log is produced each time you run the copy table program (cpytbl.exe). Copy table error messages and IDs are logged. This log also indicates whether any inserts failed that could indicate a possible error.
You use this log to view exactly what is being sent through the ODBC driver. This is not a JD Edwards EnterpriseOne log; another software vendor provides this log process.
For workstations in production environments, you can use jdeinst.log to identify faults in JD Edwards EnterpriseOne silent installation.
If you use the silent installation process for JD Edwards EnterpriseOne installations on a workstation, you can use this log to view the status of the silent installation.
The workstation jdedebug.log file contains messages relating to API calls and SQL statements, as well as other messages. You can use this file to determine the point in time when normal processing stopped. The system does not use jdedebug.log to track errors. Instead, it uses this log to track the timing of JD Edwards EnterpriseOne processes.
You can use jdedebug.log to determine where a process has ended. For example, log data can include what the ODBC was trying to connect to, the SQL statement that was being run for a specific table, and whether memory has been freed.
If the process failed and you have logging turned on, look in the jdedebug.log for these messages:
Not Found
Failure
Also, look at the end of the log to see what process ran last. In general, important lines in the log are:
SELECT
The SELECT lines indicate which table you are selecting. The log tells you in which library (for the IBM i) or environment (for the non- IBM i) the table resides. You should verify that the selected libraries and environments are correct.
ODBC Version
The ODBC lines indicate whether you are having problems connecting to the driver.
You can use the batch process log to identify faults in JD Edwards EnterpriseOne processing that are related to batch processes. The batch process log resides in the \E900\PrintQueue directory. The log file name is batch_process.log, where batch_process represents the report name, version name, date, and time.
Based on the setting of the UBESaveLogFile parameter in the [UBE] section of the jde.ini file, this log file is deleted or saved on successful completion of batch processes. This log file displays different types of messages that can help in tracking errors in the batch process. The messages are:
Section Level Process
Object Level Process
ER Level Process
DB Level Process
The batch process log can contain ER references, batch process flow, and SQL statements, among other messages. You can use the batch process log file to determine when normal processing stopped.
The batch process log file displays the process flow in batch processes. This flow is completed in these steps:
When batch processes complete a section, starting with the INIT section, a business view is opened.
After the INIT Section log, you should see a SQL statement.
After INIT Section, the batch engine calls Adv Section to retrieve a record.
After the retrieve, batch engine processes the Do Section Processing.
From Do Section, each object is processed in Init Object - Do Object - End Object order.
After Do Object message, you should see Printed value in the log.
ER events are logged in a different event level.
In sql.log, the important lines for you to search are:
SELECT * FROM (bold in this example)
SQLBindCol
Table not found
Verify that you are reading the correct table. For example, in the sql.log example, a line exists for every column in the selected table, which indicates that the correct table is selected.
If you are having difficulty reading the table, verify that the table has the correct number of columns. If you have added columns to the table and you cannot locate the correct number of columns, you need to configure the table. This information is also provided in jde.log.
You can create a normal (successful) jde.log by logging on to JD Edwards EnterpriseOne and then immediately logging off. Use this log of successful startup statements to compare against logs that have a problem.
If you know the problem is not related to startup, you can clear and save the log without quitting JD Edwards EnterpriseOne. When you recreate the problem, the contents of the log should contain only errors that occurred since you cleared the log.
You can also rename the log to indicate the kind of problem. For example, you might delete the jde.log and then run a report that causes an error condition. You could rename the jde.log to report.log.
Another alternative is to add comment lines to the jde.log indicating the sequence of events that you are performing. For example, you might be running an application that you know causes an error. Just before you run the application, you could edit the jde.log to add a comment line stating that you are about to start the suspect application.
Most error messages in the jde.log have a unique number assigned to them. You can view an extended description of the error, including possible causes and resolutions, by searching on the error number in the Error Messages application (P92002).
You can view JD Edwards EnterpriseOne log files from within any application. If you want to view log files outside of JD Edwards EnterpriseOne, you can use a text editor like Notepad or Wordpad.
To view log files:
From within any JD Edwards EnterpriseOne application, right-click to open the pop-up menu.
On the pop-up menu, select the View System Log option.
On Log Viewer, select File, Open to locate and open a JD Edwards EnterpriseOne log file.
You can also use the View menu selection to select log files. If you have viewed log files previously, the File menu keeps a history of those files.
You can use the workstation jde.log as a general purpose log to track fatal errors that are generated by JD Edwards EnterpriseOne processing. The jde.log tracks any fault that might occur within JD Edwards EnterpriseOne. When you are looking for startup errors, you should read the jde.log from the top down. For other errors, you should read from the bottom up.
The workstation jde.log is created (if it does not exist) or overwritten (if it already exists) at the start of every JD Edwards EnterpriseOne session.
To set up the workstation jde.log:
Locate the workstation jde.ini file.
The JD Edwards EnterpriseOne setup program places this file in the working Microsoft Windows directory; for example, c:\Windows\jde.ini. If you are unsure of the workstation's working Microsoft Windows directory, use the Find command to locate the jde.ini file.
Use an ASCII editor (like Notepad or Wordpad) to open the file.
In the [DEBUG] section, verify or change this setting for the job file variable:
| Setting | Purpose |
|---|---|
| JobFile= | Specifies the location and name of the jde.log file. The default value is c:\jde.log.
Note: You can disable the jde.log on the workstation by specifying a blank or invalid value for JobFile. If you delete or disable (comment out) the JobFile parameter, JD Edwards EnterpriseOne automatically creates and writes to a log file called jde.log in the c:\ directory of the workstation. |
To set up the workstation jdedebug.log:
Locate the workstation jde.ini file.
The JD Edwards EnterpriseOne setup program places this file in the working Microsoft Windows directory, for example, c:\Windows\jde.ini. If you are unsure of the workstation's working Microsoft Windows directory, use the Find command to locate the jde.ini file.
Use an ASCII editor (like Notepad or Wordpad) to open the file.
Verify or change the name of the jdedebug.log file.
The location and file name of the jdedebug.log file is defined by this setting in the jde.ini file:
| Setting | Purpose |
|---|---|
| DebugFile= | Specifies the location and name of the jdedebug.log file. The default value is c:\jdedebug.log. |
Enable or disable the logging of events to the jdedebug.log file through this setting in the [DEBUG] section:
| Setting | Purpose |
|---|---|
| Output= | Valid values are:
|
Note:
The primary method of disabling the jdedebug.log is by using the Output parameter. However, if you set Output=FILE and you leave the DebugFile value blank (or specify an invalid location), JD Edwards EnterpriseOne still performs debug tracing but does not write the results to any jdedebug.log file. If you delete or disable (comment out) the DebugFile parameter, JD Edwards EnterpriseOne automatically creates and writes to a log file called jdedebug.log in the c:\directory of the workstation.Set the level of debugging information that you want written to the jdedebug.log file.
The debug level is determined by this parameter in the [DEBUG] section:
| Setting | Purpose |
|---|---|
| Output= | Specifies the debug level. You can specify any combination of allowable values using commas as delimiters. The default setting is LEVEL=BSFN,EVENTS. Valid values are:
|
For example, LEVEL=SF_CONTROL. In addition, you can specify multiple system functions by separating them with commas. For example, LEVEL=SF_GRID,SF_CONTROL. You can also specify numeric values:
1: Traces critical errors. This is the default level. That is, whether you specify this value or not, the system will always trace critical errors.
2: Traces critical errors. This is the default level. That is, whether you specify this value or not, the system will always trace critical errors.
3: Traces statements as the software enters and exits each event. Specifying this value is the equivalent of specifying the EVENTS value.
4: Traces main messages that the software sends to a controlling parent of a child. These messages concern the processing functions such as the grid.
5: Provides a detailed trace report of every function that the software calls in the interactive runtime module. This setting is applicable only to developers of the runtime module.
Save the changes and close the jde.ini file.
To set up the batch process log:
Locate the workstation jde.ini file.
The JD Edwards EnterpriseOne setup program places this file in the working Microsoft Windows directory, for example, c:\Windows\jde.ini. If you are unsure of the workstation's working Microsoft Windows directory, use the Find command to locate the jde.ini file.
Use an ASCII editor (such as Notepad or Wordpad) to open the file.
Set the level of batch report debugging information that you want written to the batch process log file, and set whether you want the file to be saved.
These settings are controlled by these parameters in the [UBE] section:
| Setting | Purpose |
|---|---|
| UBEDebugLevel= | Specifies the level of UBE debug logging. The default value is 0, and values are:
|
| UBESaveLogFile= | Specifies whether the <batch_report>.log file will be saved. Values are:
|
Save the changes and close the jde.ini file.
For JD Edwards EnterpriseOne workstations in development environments, use this log to identify faults in JD Edwards EnterpriseOne processing that are related to compiling and generating applications and business functions. This log for compiled event rules provides an account of event rules (Named Event Rules, Table Event Rules, and applications) that do not properly compile and process. JD Edwards EnterpriseOne generates this log file every time the Code Generator program (cg.exe) is run and errors occur with compiled event rules.
The <compile_error> portion of the log file name refers to a variable value for the name of the event rules being compiled. For example, a name of a log file for compiling NER N3200780 is N3200780.log. The error log from an application containing compiled event rules replaces the first letter of the application name with an E; for example, P0101 generates an error log named E0101.log.
Use this log when errors have occurred within the Code Generator while you were compiling an application, Named Event Rules, or Table Event Rules. When this happens, a message box appears beneath the JD Edwards EnterpriseOne Code Generation form with the source member and the problem description. You can use the log file to keep a record of such problems. The compile error log resides in the log folder under the path code portion of the E900 directory tree, for example, c:\E900\PD900\LOG.
The system produces output for jdecpy.log each time the copy table program (cpytbl.exe) is run on the workstation. In general, the file contains records of those tables that were successfully copied from the local database to the chosen server. This log also indicates whether any inserts failed. Such failures indicate a possible error. This log is automatically stopped after cpytbl.exe finishes.
The jdecpy.log resides in the root directory of the workstation, usually in c:\. JD Edwards EnterpriseOne automatically generates this log every time you run cpytbl.exe. The log is created or overwritten each time it runs.
After you use jdecpy.log to determine that a copy table error has occurred, you should refer to the jde.log. If a table does not copy properly, the detail of the error text is written to jde.log. The jde.log contains the actual error message and message ID. The message ID relates to the line prefix numbers in the jdecpy.log. This ID will help you locate the applicable error text that was written to the jde.log.
You can use sql.log to view exactly what is being sent through the ODBC driver. This log is not a JD Edwards EnterpriseOne log; another software vendor provides this log process. For workstations, sql.log resides in the default root directory of the workstation, usually in c:\. You can direct the output to any file in any location. In general, instead of using the sql.log, you can use the jdedebug.log because it also tracks SQL statements.
In sql.log, the important lines to search for are:
SELECT * FROM
SQLBindCol
Table not found
If you experience a problem with the ODBC settings or can't connect to a JD Edwards EnterpriseOne ODBC database, activate logging for jde.log, jdedebug.log, and sql.log. Duplicate the problem, check jde.log or jdedebug.log to view the ODBC error messages, and check the end of sql.log to determine the last process. The majority of ODBC problems occur when these processes are called:
Process SQL Statements
Receive Results
To activate sql.log:
On Data Sources, click Options.
Note:
Leave the Stop Tracing Automatically option selected. Because this log grows rapidly, we recommend that you stop the trace in this way to preserve disk space resources and CPU cycles.Ensure that Trace ODBC Calls is cleared when you are not debugging. The log files can consume large amounts of disk space as well as CPU cycles.
To troubleshoot ODBC problems using sql.log:
Ensure that the data source names are set up correctly (as system data sources) and that a driver has been set up in the 32bitODBC in Control Panel.
Make sure that Client Access has the correct parameters.
Ensure that the library to which you are pointing is set up correctly.
Look for these ODBC error messages in jde.log and jdedebug.log:
Table not in library
If the table that is specified couldn't be found in the specified location, go to the appropriate DBMS and attempt to locate the table.
If the table does not exist, you must generate the table.
If the table exists but has been moved, you must change the data source to point at the new library.
Not Binding Column Data Types
This error message means that the row is in use and that another program has a lock on that data. As a result, you cannot use this row until the program that is currently using it releases it.
Use jdeinst.log to view the status of the JD Edwards EnterpriseOne silent installation. The silent installation mode enables you to submit a workstation installation request through command line arguments. JD Edwards EnterpriseOne creates a log file that records error conditions that were encountered during the silent installation, and it indicates whether the silent installation was successful. The jdeinst.log file is located in the root directory of the workstation.