Record Locks - F00095

yalumba

Member
Has anyone any experience in Record locks in F00095. We are currently releasing using the P00095 each day to do a clean up. Main issue seems to be with the F4101 and F41026
Regards
Graham
 
Yes. I experience it with HR apps. I have to occasionally go to P00095
and delete them. I had put in a call to JDE, and they just told me that I
would need to delete them occasionally. No "fix" was offered.


SHONDA WILLIAMS
Glazer's Wholesale Drug Company, Inc.
JDE Systems Analyst/Developer
972-392-8308

Enterprise One 8.93.S1





yalumba <[email protected]>
Sent by: [email protected]
05/17/2006 09:13 AM
Please respond to
JD Edwards EnterpriseOne <[email protected]>


To
[email protected]
cc

Subject
Record Locks - F00095






Has anyone any experience in Record locks in F00095. We are currently
releasing using the P00095 each day to do a clean up. Main issue seems to
be with the F4101 and F41026
Regards
Graham
Enterprise One 8.11 SP1 Tools 8.95=5FH1 Oracle 10g on Windows 2003
 
I have some info for you, but it was composed on Xe.

Too many records in the F00950 can cause memory performance issues.

Estimate the average number of records per user. The total record count for a single user is determined as follows:

All *PUBLIC Records + all records of type APPLICATION EXCEPTION + all GROUP records for the user's GROUP + all USER records for the user

Estimate memory usage of the application security workbench:

Number of Concurrent Users * Average # Security Records Per User * 4 KB

Compare this value to the amount of RAM on the server.


I got this from the old JDE Advanced Technology guys when learning how to audit a system. Hope it helps.
 
I have seen these issue crops up in my XE Server.
Usually it looks like some transaction is not held properly due to Network realted issues. That cause the record get Reserved on User ID.

As per my experience, at one of my client location, neywork was very poor and they face these issue most frequently.
 
One other problem we noticed (ERP 8.0 Citrix) is if users crash or they click the X instead of Close or Cancel to leave a screen, the lock records will stay if F00095. We too have to go out with P00095 and clear records from time to time.

ERP 8.0 Citrix/JAS Win, SQL
 
Just a quick note for anybody who doesn't know this about the F00095. Record locking is done by the ER code. It's not built into the tool at all. That's why you can end up with records hanging out there. If the code to clear the lock doesn't get executed (E1 crashes, user kills the app instead of cancelling out, code is buggy, etc), it's gonna stay out there in the F00095. Just FYI.
 
We have no choice but to delete the records that are causing the lock. If it is too annoying going to p00095 to clean up, you may want to create a sql script or tc to delete, scheduled to run on a daily basis but it should be based on some criteria that you think would be safe that it only delete those records that are causing the lock...
 
You can selectively turn off Record Reservation by changing the Special Handling Code to zero in the 00/RR UDC. We did this for the Billing Detail Workfile table and the Employee Master application because of the problems it caused.
 
How do you prevent potential data corruption caused by two users simultaneously updating a record? That, after all, is the purpose of the record reservation. They are there for a reason. If a developer has coded a record reservation into his application, I wouldn't mess with it. Better to fix the cause than the symptom.
 
The Record Reservation system has not worked well since it's inception. It is not using true database locking capabilities but rather a record in a table. It prevents people who have only read only access from viewing records. We have a limited staff who have write access and they don't work on the same records. We get more problems with lockups when tracked items are being written to history than anything else. Of course, when the system locks, the record doesn't get deleted. JDE has refused to address this issue unless they can duplicate it. Sometimes you can go days without a lockup. Our staff would rather reboot rather than wait several hours while a support person dials in, just to have them reboot and not be able to duplicate the lockup.
 
Is the PID populated in the F00095? I'd look there first. The object that is putting the lock in should generally be the object that removes the lock. That could tell you where the problem is.

I worked with Yalumba on some issues a long time ago. Glad to see they are still on the software.
 
Thanks to all for your feedback. It's not a major issue at the moment so long as we keep the file clear. Seems the largest culrpits are the P4101 and P41026 appliations
Best regards
Graham
 
I Find a Bug about P41026 and F4102.

Bug 12908025 : P41026 F4102 RECORD RESERVATION
 
A long time ago, we implemented a custom UBE that deleted locks longer than 24 hours old. With Citrix timeouts / users not closing properly, the locks would sit out there for WO's as well as PO's. We also gave some rights to MFG supervisors to clean up WO locks on their own (with strict security to make sure they can only clear WO locks in their branches.) Went from 1 - 2 calls a day to maybe 1 every few months.
 
TFZ,

Would you be able to share this custom UBE that deletes locks longer than 24 hours old, and do you have it where that time can be adjusted?

Thanks!

Chris
 
Why worry about locking F4101 and F4102. The risk is minimal compared to the trouble you can run into.
 
Back
Top