4gl problem 
Author Message
 4gl problem

I have 4gl 4.00.UC1 for Interactive Unix... I am having the following problem.

I have written a module that queries from 2 tables (using an outer join) with a
scroll cursor. The user (after querying) can then update one of the rows that
are returned by using fetch_next and fetch_prev.

My Prob: The date is updated, BUT if a user updates a row and the does a next
followed by a previous (fetch_next and then a fetch_prev) the data displayed is
the OLD data... but if the user selects the same row on a subsequent query, it
refelects the changes. Why must the data be re-selected?

Here is the structure...

first the data is fetched into gr_client.*
                                                                 and
                               gr_cladd.* for the simple purpose of the select
                                                                                  only.

then I declare an update cursor for both with hold and for update. I issue a begin work.  I open these cursors and fetch them into the gr_client.* and
gr_cladd.* variables. Then I do an input by name without defaults on each column in the order they appear on my form. Next I have an update client and an update cladd statement followed by the lock_cursors being closed and then a call to my
display_client call which simply displays gr_client.* and gr_cladd.* on the
form again.... BUT.... why is the updated data not displayed when I do a next
then a previous?? Am I missing a step in making my gr_ variables equal to the
data just inputted??? PLEASE HELP!

--

-John C. Musselman               are mine and         (but we can share
-National Tel-Tec Inc.             mine alone......    if you like....)



Fri, 14 Jun 1996 02:15:44 GMT
 4gl problem


Quote:
} I have 4gl 4.00.UC1 for Interactive Unix... I am having the following problem.
}
} I have written a module that queries from 2 tables (using an outer join) with a
} scroll cursor. The user (after querying) can then update one of the rows that
} are returned by using fetch_next and fetch_prev.
}
} My Prob: The date is updated, BUT if a user updates a row and the does a next
} followed by a previous (fetch_next and then a fetch_prev) the data displayed is
} the OLD data... but if the user selects the same row on a subsequent query, it
} refelects the changes. Why must the data be re-selected?
}

What you might want to try is this...  First declare a scroll cursor that
selects just ROWIDs based upon a user's search criteria.  Next declare an
update cursor that selects the actual data based on the ROWID from a fetch
of the first cursor.  You'll be using the scroll cursor to do your next
and previous movment and the update cursor will guarantee that your data
is always current.  This was the approach I took in the very first release
of db4glgen.  I've since gone with dynamic memory management of rowids.

DAS
--

                                                              is db4glgen-3.17



Fri, 14 Jun 1996 12:58:03 GMT
 4gl problem

Quote:
John Musselman writes:
> My Prob: The date is updated, BUT if a user updates a row and the does a next
> followed by a previous (fetch_next and then a fetch_prev) the data displayed is
> the OLD data... but if the user selects the same row on a subsequent query, it
> refelects the changes. Why must the data be re-selected?

Your problem can be solved by using two cursors. You need to declare the first
cursor for the given criteria and store only ROWIDs of the selected rows.
Based on these rowids you declare another cursor to get required columns.
This approach will ensure that you always get the most current data.

Alternatively, you can SET ISOLATION LEVEL TO COMMITTED READ. But to use this
isolation, you have to COMMIT WORK to release locks placed by the update
process, as this isolation does not return a row that has not been committed.

Regards.

-Rajhans.

--------------------------------------------------------------------

CSC Intelicom                      Voice   : (303) 643 1476
116 Inverness Drive East           Fax     : (303) 792 0319
Englewood, CO 80112                Standard Disclaimers Apply.
--------------------------------------------------------------------



Sat, 15 Jun 1996 01:38:02 GMT
 
 [ 3 post ] 

 Relevant Pages 

1. Annoying 4GL problem

2. 4gl problem

3. 4gl problem-jmuss

4. 4GL Problem

5. 4GL Problem

6. 4GL-problem

7. preparing select in 4GL problem

8. DOS 4gl problem

9. 4GL Problem

10. Informix 4gl Problem

11. 4GL problem

12. 4GL problem


 
Powered by phpBB® Forum Software