File NEED, PUT (Was: Update Out of Sync)
Darren Reely
darren.reely@latticesemi.com
Fri, 15 Feb 2002 09:44:14 -0800
Bob,
That clears up my understanding of the problem.
Note that I do have an item statement with final, but it is conditional on
the record being altered. So of course never triggers in my case.
item last_mod_date final sysdate if alteredrecord of product_ms
I do have a solution where I save the original value into a temp item for
testing before trying to update my designer file. It works great.
Thank you,
Darren
"Deskin, Bob" wrote:
>
> You have a couple of issues.
>
> First the NEED. It really makes sense on NEW records only. If you have an
> old record and change a value, the status is changed and the update occurs
> regardless. Even if you have an ITEM FINAL and an old record, the update
> occurs because ITEM FINAL is evaluated for old records whether or not they
> are changed. For NEW records, unless the user or developer (via procedures)
> change the value, it's unchanged. And an ITEM FINAL does not get executed
> for new, unchanged records. So NEED was developed to allow developers to
> force an update using ITEM FINAL values only. In your case, I don't think it
> does anything.
>
> The second is a timing problem. Unless everything is locked up tight and a
> read-write transaction is started when you read the primary, I would
> recommend re-retrieving the primary in the postupdate. You might want to
> start your own transaction in the PREUPDATE and COMMIT in the POSTUPDATE. As
> it is you're assuming that nothing has changed since the the primary was
> first retrieved and the use of the value in the POSTUPDATE.
>
> The other alternative is to modify the UPDATE procedure by adding the
> postupdate code. That way QUICK handles commits and rollbacks.
>
> Bob Deskin
> PowerHouse Web Product Manager, Application Development Tools, Cognos Inc.
> bob.deskin@cognos.com (613) 738-1338 ext 7268 FAX: (613) 727-1178
> 3755 Riverside Drive P.O. Box 9707 Stn. T, Ottawa ON K1G 4K9 CANADA