in the latest release of HR Renewal, there are various level of complexity introduced in the process of updation of the infotype records. What could be probably happening is that down deep the infotype framework layers, we perform an as-synchronous update for updating the database. While the as-synchronous update is processed it's not possible to issue another lock on the pernr. This updation process is little more complex in the HR_Renewal. Hence, the as-synchronous update is taking little bit more time than before. During the update process, the sap luw will not allow another Exclusive lock on the pernr. However, in the application program you're trying to lock indivigually for each record for the same pernr. By the time, the first record is being as-synchronously updated. There is request for another lock. the programs is working in the debug mode. Since a natural delay is introduced during update, the locks are successfully issued. There are two options that you could do. 1) You can introduce a delay within the loop. Please refer to the abstract code comments. loop at pernr_table. Perform enqueue. Perform infotype_operation. Perform Dequeue. introduce delay. endloop. 2) The Second approach is to change the logic of the program. In your application you are performing lock on every record of the same pernr which is not necessary. This should counter the as-synchronous update delay issue.
Please check this as well the Function module 'HR_INFOTYPE_OPERATION'. Inside this Function module there is a call to 'HR_MAINTAIN_MASTERDATA'. While calling 'HR_MAINTAIN_MASTERDATA' the parameter NO_ENQUEUE is passed with a value of space. In our standard internal systems NO_ENQUEUE parameter is passed with a value of 'X'. This change is causing the error.