File NEED, PUT (Was: Update Out of Sync)

Deskin, Bob Bob.Deskin@Cognos.COM
Fri, 15 Feb 2002 08:40:43 -0500


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

-----Original Message-----
From: Darren Reely [mailto:darren.reely@latticesemi.com]
Sent: Thursday, February 14, 2002 8:11 PM
To: 'powerh-l@lists.swau.edu'
Subject: File NEED, PUT (Was: Update Out of Sync)


What I really wanted to know was...

If you place NEED on a file statement, is the PUT suppose to be executed
even when no data has been changed for the record?

In my case, I know the UPDATE procedure must be executed because User 2 did
make a change to the DETAIL record which does get updated properly.

Thanks,

Darren

P.S. This is not problem of two users updating simultaneously.  They have
fetched the identical record before the other person has done an update. 
But their updates could occur several minutes apart.


Darren Reely wrote:
> 
> Hi All,
> 
> I have a screen that two users can update fields from different records.
> Unfortunately we duplicate one of fields from the primary record to
another
> table, but this can fail when two users are in the screen performing
> updates.
> 
> Here is the scenario.
>   User 1 & 2 both pull up the same data at the same time.
> 
>   User 1 changes a value in the primary record.
>   User 1 performs an update which does the 'put product_ms'.
>   User 1 update performs postupdate procedure to copy the column
>          to the other table.
> 
>   User 2 changes a value in a detail record.
>   User 2 performs an update, which skips the 'put product_ms' since
>          no fiels were changed for it.
>   User 2 update performs postupdate with old value that user 1 changed.
> 
>   The columns are now out of sync.
> 
> Refer to code below if needed.
> 
> Now for my question.  Why when I've added 'NEED 1' to the primary record,
> does the 'put product_ms' not get performed?  The proof is that the new
> value is still in the record after the second user has updated his 'pmy'
> record change.  I thought placing a NEED on a file statement forces an
> update.  Am I misunderstanding this.  No errors or warnings are returned.
> 
> I think my solution will be to check if the field in the primary record
has
> changed. If so, only then do the update of the other table.  My other
> solution is to use a trigger.
> 
> System is:
>  PH 8.13.D1
>  Sun Solaris 2.6
>  Oracle Release 7.3.4.4.0.
> 
> file product_ms in mfg PRIMARY NEED 1
> file product_ms_yield in mfg alias pmy DETAIL occurs 2 noitems
> file tester_forecast_yield in mfg designer
> 
> procedure update
>  begin
>     put product_ms
>     for pmy
>         put pmy
> end
> 
> procedure postupdate
> begin
>   while retrieving tester_forecast_yield via prod_line, ms &
>        using prod_line, ms of product_ms
>     begin
>        let gross_die_waf of tester_forecast_yield = gross_die_waf of
> product_ms
>        put tester_forecast_yield
>     end
> end
> 
> Thank you for your time.
> 
> Darren
> 
> P.S.  The surprise is that this 5 year old bug (before my time) has only
> thrown out 11 records total this year and last.  Also lucky, is the small
> difference.
> 
> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> Mailing list: powerh-l@lists.swau.edu
> Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
> Unsubscribe: "unsubscribe" in message body to
powerh-l-request@lists.swau.edu
> http://lists.swau.edu/mailman/listinfo/powerh-l
> This list is closed, thus to post to the list you must be a subscriber.

= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l@lists.swau.edu
Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
Unsubscribe: "unsubscribe" in message body to
powerh-l-request@lists.swau.edu
http://lists.swau.edu/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.

This message may contain privileged and/or confidential information.  If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.  Thank you.