Hi,

In a type 3, 'Maintain' session, I need to

#1 - update records in main table itself before displaying them
#2 - update records in a different table.


Q1
#2 is simple enough but #1 is giving me some frustrating errors (either transaction is on, or record not locked). What is the best way to do this?

Q2
Currently the update is called within section "before.display.object'. Should these updates instead be called from before/after.read of main table?

Q3
I've read some posts on using "select for update" vs "select [without "for update"]. Which should I use... in this case?

Thanks in advance

Okay - been thinking about this. In most of my sessions I am updating something within the confines of the program itself - using before.program or find, something like that. The question I have is if you are getting transaction is on then that means the program thinks it has already started a transaction - which means you should not have a retry point or a commit in your code. You may just want to try execte(update.db) instead. Not sure this will work.

Thanks Mark,

Given the 2 examples (1-Update maintable, 2- update other table), when should I
a)select for update,
b)select but NOT for update, or
c)simply update.db

?

It depends on the situation. So for example this is a qkey session that I use the main.table.io sections to update a different table. This is one way to do this. In this case it takes additional form fields used for input and then goes and updates the custom table. This is an extension table for maintain employees. Doing this is a method for us to not modify the main table and allow us to input additional information we need.


main.table.io:
after.read:
|#call
get.emno.table()

after.rewrite:
|#call
update.emno.table()

after.write:
|#call
update.emno.table()

after.delete:
|#call
delete.emno.table()

function update.emno.table()
{
select tcudi005.*
from tcudi005 for update
where tcudi005._index1 = {:tccom001.emno}
selectdo
db.update(ttcudi005,db.retry)
commit.transaction()
selectempty
tcudi005.emno = tccom001.emno
db.insert(ttcudi005,db.retry)
commit.transaction()
endselect
}


In this example I build the records for the main table as the users are working. I do this with the start set and with the continue button. Keep in mind I eliminated a lot of code to keep this post short.

choice.start.set:
after.choice:
load_tdapi435()
choice.cont.process:
on.choice:
load_tdapi435()
db.retry.point()

function load_tdapi435()
{
select ticst001.*
from ticst001
where ticst001._index1 = {:tdapi435.pdno}
and ticst001.ques <= 0
selectdo
select tdapi435.*
from tdapi435 for update
where tdapi435._index1 = {:ticst001.pdno, :ticst001.opno, :ticst001.pono}
as set with 1 rows
selectdo
tdapi435.user = baan.user
db.insert(ttdapi435,db.retry)
endselect
commit.transaction()
endselect



I could not find an example of one that just did a select/update in the before program step. The issue becomes what you want to happen where and why. Sometimes it is not so easy to find every little event that affects your code. Keep in mind I do 4c4 and not the other versions.

Hi Robert,

Comment out all occurences of db.retry.point() and in after.write section of main.table.io you can code your required update statements for tables other than main table.

Hope this will help you out!!!

Thank you very much Mark and Baan Guru.

If I can ever help let me know ok. Have done alot of work on GBF... painful.. but I have some pretty funky scripts.

Hi Mark,

Quick question, why have you set the db.retry point after the update of table in choice.cont.process?

Very good question - I will have to check my code, but it looks kind of useless.

For Mark, just a question:
Nice the use of reactivating the retry.point() after the commit, but what could happen if, for some reson, maybe the record locking of the main table (I think is the ticst001 table) in the normal update (it is clear what happens if the function hits the retry point with a recors is changed error by example at record of tdapi435, or almost I try to figure it)? Have you tried? Maybe this never happens, but...?

Just curious about it ;)

But, for RobertP:

If you update the table in before.display.object, I think that this happens each time the object is displayed, so each time a next screen or even go down 1 row happens. So a lot of updates happens each time you scroll the screen.
Maybe the reason is that table collects data in real time or something like this, so from a logical point of view this could be right.
But IMHO is preferable to do before entering the program (at the start of the program data is almost correct) and doing the same at user command, because the user must be responsable of the fact that the data are updated not real time (what happens if the user goes to lunch and after one hour reads the screen seeing no changes? I doesn't know that data are refreshed periodically - and maybe doesn't knows haw the system real works ;) )

For Mark, just a question:
Nice the use of reactivating the retry.point() after the commit, but what could happen if, for some reson, maybe the record locking of the main table (I think is the ticst001 table) in the normal update (it is clear what happens if the function hits the retry point with a recors is changed error by example at record of tdapi435, or almost I try to figure it)? Have you tried? Maybe this never happens, but...?

Just curious about it ;)

It is actually a typo. Not sure why cut and paste did not work. It must have been when I removed some of the comments.


function load_tdapi435()
{
db.retry.point()
select ticst001.*
from ticst001
where ticst001._index1 = {:tdapi435.pdno}
and ticst001.ques <= 0
selectdo
select tdapi435.*
from tdapi435 for update
where tdapi435._index1 = {:ticst001.pdno, :ticst001.opno, :ticst001.pono}
as set with 1 rows
selectdo
tdapi435.user = baan.user
db.insert(ttdapi435,db.retry)
endselect
commit.transaction()
endselect