How to analyze a new bug

1. to get a new bug, we must first reproduce the problem. this is necessary for the code issue, and it is almost necessary for the customer's data issue. if it is a code problem, you cannot modify the code without recreating it. If it is changed, you cannot verify whether it is correct. most of the customer's data problems can be reproduced. after all, the customer uses our system to operate. As long as the customer's historical data is obtained, the customer can make the same data by themselves. in the past, I used to give scripts because I didn't like to reproduce the data fix. however, this often ignores some important data and is prone to errors. if the data fix is determined, the default code is correct. The script should be consistent with the result obtained by correct operation on the system.

2. after recreating the bug and familiarizing yourself with the entire process, you will know where the problem is and what the correct behavior should be. at this time, we did not rush to analyze, but to search. what are you looking? It is to find out if the previous person has encountered the same problem. the search is mainly in the Bug system and on the Support website. the Bug system contains historical data about all bugs. similar or even identical bugs can be found based on keywords. let's see how it was solved. this is especially useful for data fix, because the probability of data problems in the same issue is relatively high, refer to the previous script can reduce a lot of work. the Support website has many notes written by developers and support. You can find similar problems by searching for keywords. this code fix is very useful. if the code problem has been solved before, simply patch it with the note.

3. if the code fix cannot be reproduced, this problem has been changed in most cases. the customer still has this problem because of the low file version. go to the above two websites to find the corresponding patch.

4. If no similar bugs are found on the two websites, congratulations, you have encountered a new problem and you have to analyze it from the beginning.

5. The analysis tool is nothing more than log. Check the log to track where the code is going. For our INV team, several common logs are:

A) INV log

INV log records the process of the server code, that is. pls file log. if FND_PROFILE.VALUE ('inv _ DEBUG_TRACE ') is read at the beginning of the file, the log of this file is recorded in the INV log. this log is useful for analyzing the code.

B) RTP log

RTP log is the log recorded by the system running concurrent request: Processing ing transaction processor. if you have played 9184617: R12.PO. A patch, that is, rvtpt. the lpc version is later than 120.19.12000000.25, so you can see the RTP log in the INV log. if this patch has not been applied, you can only collect it in the old way. the method to collect is to record the RTP id, and then use the following SQL:

    select module, to_char(timestamp,'DD-MON-YYYY HH24:MI:SS'), message_text    from fnd_log_messages    where timestamp > sysdate - 2/24    and process_id = ( select os_process_id from fnd_concurrent_requests where request_id = &request_id)    and module like 'po%'

C) FRD log

The full name of FRD is forms runtime diagnostics, which records the logs of all triggers during form running. in this example, we can clearly see the trigger sequence and what is done in it. if the customer's bug is caused by an error reported by the form runtime process, the error will be displayed in the trigger, and the task is to read the code.

D) SQL trace

SQL trace records all database operation logs. including all operation statements, binding values, performance problems, and SQL errors. if you find the SQL statement by checking the error message, half of the problem is solved.

E) fnd_new_messages

This is a database table that records all error information. If the customer reports an error, you can use the following SQL statement to find the corresponding error record.

select * from fnd_new_messages where message_text like 'Quantity entered should be less than or equal to available quantity%'

Then you can find the Error Report in the Code. Generally, an error message is reported only in one place, so it is easy to find the corresponding code.

Through the above several logs, We can almost locate the code where the bug occurs. The next thing is to fix the code or provide the script to the customer.

The last important point is that, whether the code fix or data fix script is provided, you must review other development tasks to avoid problems.