hi guys, i currently have the FRM-40654 record has been updated by another user, re-query to see changes. I have searched this form for posisble solutions as well as other websites, i dont seem to have a missmatch of dates, or any data type, i dont seem to have trailing spaces or anything like that, basically i cant seem to spot the missmatch between my database and the output in forms so what im asking is: do any of you know a method i would be able to use to discover the missmatch?
BTW i am the only one logged on so there is no way it can be another user editing the record.
btw this occurs when i update a record and save it and then go to change the same record again.
Any help would be GREATLY appreciated as this is a very annoying problem as i cant even find out what the problem is.
p.s.some of the items in my datablock are not displayed on the form for the user to see, such as user created, date created etc, would this have anything to do with it?
I have had this same thing happen, but what it was in my case is calling a stored procedure (package/procedure) where that procedure is updating a record. Since the data is being updated on the database and doesn't match forms - in honks with that error. I did what it said, and just re-queried the record after the return from the database.
So... I would look for a call to a stored procedure and see if that is what is happening.
would it be anything to do with that the following items from my datablock are inserted by the database: user whom created the job, date job created, user whom last updated job, date job updated, and each job has a job id which has a unique id generated bya sequence on the database.
All these values are input via the database and not forms triggers, do you think this could be the cause of the problem? if so any suggestions on what to do about it?
I'm not sure I understand. Are you saying that you have database triggers that are populating those values? If so, then yes that would cause your problem. You would need to remove that logic from the database triggers and stick it in your pre-insert and pre-update triggers. We had a developer do the same thing and had to move the logic.
If you have triggers that update insert or update columns like primary key, audit info etc. you can set DML Returning Value property of the block to Yes.
"A database update or insert action may initiate server-side triggers that cause alterations or additional changes in the data. In Release 6, when using an Oracle8 database server, Forms uses the DML Returning clause to immediately bring back any such changes. When this property is set to Yes, Forms will automatically update the client-side version of the data, and the user will not need to re-query the database to obtain the changed values."