we have a scheduled job that runs and deletes certain records and inserts others..
for years, this has worked while users were in the table via oracle forms 10g
after upgrading to forms 11g the tables are locked while users are in the forms and the scheduled job will fail, causing many other issues..
I'm sorry, but my programmers have not given me any further details that I can use to troubleshoot the issue..
The record locking behavior of Forms has not really changed since 10.1.2. So, if you are seeing a difference in behavior there is more to the story. For example, it is possible that for some reason you are ending up with orphaned runtime (frmweb) processes on the server. This could result from users closing the browser while the form is busy. It could also be caused by network issues or a variety of other possibilities. The point is that if records were locked by a user and their session does not terminate in a clean manner, those locked records will remain locked until their session terminates. In most cases, this is handled by FORMS_TIMEOUT. The default value is 15 minutes. This means that after 15 minutes, if the runtime process has not heard from the client it will be terminated. However, in some cases, if the form was busy when the client vanished, the runtime may go into an unstable state and not be able to shutdown. Unfortunately, little can be done with this. Those processes will need to be killed manually.
1. Never set FORMS_TIMEOUT to a value too large. The longer an orphaned process remains on the server the longer it will waste resources. Generally the default value is perfect.
2. Never set the Forms HEARTBEAT value to something larger than FORMS_TIMEOUT. This can cause orphaned runtime processes when the client is killed.
3. Ensure that you are running the latest patch release for your version. In other words, for Release 1 you should have 220.127.116.11 and for Release 2 you should have 18.104.22.168
4. Although it is not required, regenerating your X files (fmx, mmx, plx) after installing a full patch is a good practice. Also including the compile_all=yes option when generating those files will help to ensure a proper internal cleanup occurs.