Re: Forms 4.5, Personal Oracle7 & FRM-40654

In article <pconnors.799230321_at_BIX.com>, pconnors_at_BIX.com says...
>
>lmayhew_at_ionet.net (Lee Mayhew) writes:
>
>
>
>>This works fine for the first update or insert. But when I try to
 update
>>a record for a second time I get a "FRM-40654: Record has changed.
>>Re-query to see changes.". The cause of error in the book says another
>>user has changed the row. I don't understand this since I am runing
>>Personal Oracle.
 

>>Any ideas or suggestions?
>
>
>That's a badly-written error message, combined with a limitation
>in Forms which goes back a way and would be really tricky to fix
>given the way Oracle works.
>
>First, what's happening to you has also happened to me on Unix
>versions of Oracle where I'm the only possible user for a table and
>form. What happens is this: You update a record and commit it.
>The rowid of the row you updated may have changed, or it may not.
>Forms assiumes the worst-case (rowid changed), and releases its
>pointer to the rowid. The only way to get that pointer back is to
>re-query.
>
>The simplest way around that is to make all of the necessary changes,
>THEN commit. But that may not be possible for your application. So
>you could capture the key fields, and then write a key-commit trigger
>that does the commit, then uses the key fields to re-query the row.
>
>There's probably other ways around this, but these are the two I've
>encountered.
>
>-Pat Connors

Thanks for all the comments and suggestions... After a little playing around with Forms 4.5 and some data this weekend. I noticed that I didn't get the FRM-40654 when I used a VARCHAR2 variable on a second update. I was using CHAR variable. I changed all of my CHAR variables to VARCHAR2 and it seems to work fine.

I am sort of clueless is to why one works and the other does.. But anyway beware of the CHAR variable.

Lee Mayhew

a CHAR type variable Received on Mon May 01 1995 - 00:00:00 CEST