| frm-40654: record updated by another user [message #82034] |
Mon, 14 April 2003 07:33  |
kim
Messages: 116
Registered: December 2001
|
Senior Member |
|
|
hello,
i am getting the error "frm-40654: record has been updated by another user. re-query to see change." this is happening if i commit my form and then try to update data. no one else is using this database/form, so why am i getting this error? thanks.
|
|
|
|
|
|
|
|
|
|
| Re: frm-40654: record updated by another user [message #82050 is a reply to message #82039] |
Wed, 16 April 2003 06:22  |
kim
Messages: 116
Registered: December 2001
|
Senior Member |
|
|
here is my code:
procedure commit_changes is
begin
calc_chk_wt;
calc_screens;
calc_chk_pct;
commit;
end;
the three other procedures are used to do some calculations. it still isn't working, what else can i try? thanks.
|
|
|
|
| Re: frm-40654: record updated by another user [message #82052 is a reply to message #82039] |
Wed, 16 April 2003 10:06 |
Julie
Messages: 98
Registered: February 2002
|
Member |
|
|
Kim,
When I had this problem before, it was because some of the inate behavior of my form was changing a value in one of the database columns on the form. It can be a column with a LOV set to validate that is changing the value of a column. Or, it can be that there are trailing spaces in your data that the form is truncating, then finding different.
It's an annoying problem, but try to think in terms of what data is your form changing for you.
Good luck.
|
|
|
|
|
|
| Re: frm-40654: record updated by another user [message #82073 is a reply to message #82034] |
Fri, 18 April 2003 05:22 |
Sun
Messages: 92
Registered: August 2002
|
Member |
|
|
Did u created the layout through wizard or manual. If u might have created manually... one chance is u might have forget to set the primarykey value. property in the item. check the primary key values. (What r all the primary keys given at the time of creating the table.)
The second thing is are u entering all the values are assigning some values. If u are assinging, check the update allowed property... it may also create the problem...
|
|
|
|
|
|
|
|
| Re: frm-40654: record updated by another user [message #201040 is a reply to message #82034] |
Thu, 02 November 2006 05:49 |
yogen
Messages: 39
Registered: October 2006
Location: UK
|
Member |
|
|
I also got the same problem.
i executed this query in database.
select * from dba_objects
select do.object_name,sid,s.serial#,s.osuser,
row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#, --s.session_id,
dbms_rowid.rowid_create ( 1, ROW_WAIT_OBJ#, ROW_WAIT_FILE#, ROW_WAIT_BLOCK#, ROW_WAIT_ROW# )
from v$session s, dba_objects do
where s.ROW_WAIT_OBJ# = do.OBJECT_ID ;
and from this query i could see the locked object in the database.
identify the concerned table which is locked and release the lock by killing the session usin sid and serial# value.
I think this must help you.
|
|
|
|
| Re: frm-40654: record updated by another user [message #310720 is a reply to message #82034] |
Wed, 02 April 2008 03:52 |
amcminn
Messages: 1
Registered: April 2008
|
Junior Member |
|
|
I have spent a while trying to fix this issue as i was having the same error, and im relatively new to Oracle forms.
The fix for me was as mentioned above, i.e. the primary key was not set on the data block that seemed to be causing this issue.
Thought I'd throw this up in case it may point someone in this direction.
Thanks.
|
|
|
|
|
|
| Re: frm-40654: record updated by another user [message #310933 is a reply to message #310767] |
Wed, 02 April 2008 20:14 |
solisdeveloper
Messages: 48
Registered: March 2008
Location: Mexico
|
Member |
|
|
Hi:
I went through the same just recently.
I was calling a procedure to update several tables and then I used "COMMIT". The data was updated, but i was getting the same error message. Then I realized that it was being triggered by the "when-new-record-instance" somehow after commiting my form was creating or navigating to a new instance of a record in my block (changed-status)and what worked for me was to clear the form.
I hope this helps!
|
|
|
|
|
|
|
|
|
|
|
|
| Re: frm-40654: record updated by another user [message #381705 is a reply to message #82034] |
Mon, 19 January 2009 06:04 |
sheeba28
Messages: 4
Registered: September 2005
Location: Bangalore
|
Junior Member |
|
|
I had the same issue and was trying all the solutions mentioned above. The difference was I was querying the record.
Mine was one column has the value as 'NULL' for some records. Someone had done manual insert 'NULL' instead of NULL.
And this is solved.
Thank you everyone.
Cheers!
|
|
|
|
| Re: frm-40654: record updated by another user [message #388144 is a reply to message #82034] |
Mon, 23 February 2009 07:44 |
lykmyk
Messages: 9
Registered: March 2007
|
Junior Member |
|
|
Hello:
If you are getting this issue "frm-40654: record updated by another user" then you need to first ensure that primary keys are set correctly on the underlying tables.
Oracle by default will try to place a lock on all records that share a foreign key.
|
|
|
|
| Re: frm-40654: record updated by another user [message #440128 is a reply to message #388144] |
Thu, 21 January 2010 04:12 |
shmuel
Messages: 1
Registered: January 2010
|
Junior Member |
|
|
The FRM-40654 might also be caused by the following bug in Virtual Private Database (VPD).
Suppose you try to update a detail table of which the VPD predicate checks existences of a row in a master table. Let VPD allow update of this detail table. Assume that the master table has a policy which does not allow update of the master. Then a select for update displays NO rows erroneously. When a field in a form is updated, then the forms engine carries out a select for update in order to lock. Therefore, the form receives the message '0 rows updated' and is fooled into thinking that someone changed the record, whence the message. This is Oracle Bug 7344505 as mentioned in metalink ID 759252.1, which refers to the 'Oracle database team' for a solution. (A trace revealed that VPD computes and applies the master predicate twice.)
A bypass is to create an on-lock trigger which turns VPD off, places a lock, and turns VPD on again. This trigger overwrites the standard forms lock. (You should not place the NULL statement here, for this would allow users to annihilate each other's changes without notice.) Here are some code chunks from an on-lock procedure in a general library built by CMG.
...
lv_data_name VARCHAR2(30) ;
BEGIN
...
lv_data_name := get_block_property( lcv_block_name, DML_DATA_TARGET_NAME ) ;
[set variable in stored package to bypass VPD]
IF lv_data_name IS NOT NULL
THEN
lock_record ;
IF form_success
THEN
...
ELSE
[turn bypass off]
RAISE form_trigger_failure ;
END IF ;
ELSIF lv_data_name IS NULL
THEN
execute_trigger( 'lock-procedure' ) ;
IF form_success
THEN
...
ELSE
[turn bypass off]
RAISE form_trigger_failure ;
END IF ;
END IF ;
[turn bypass off]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
This DML returning to 'Yes' works ! Mine was a different issue, the error was coming up after I post the record for next columns ! But anyway, it works fine ! Thanks a ton. 