mark_h
12th July 2003, 01:14
Okay - what am I doing wrong and how do I solve this problem. I need to select some records on tpppc211, reverse them, then split the costs, then update the tpppc211.loco field so I know this record has been processed. I have tried a ton of different methods with a variety of errors. I know I am losing a pointer somewhere, but can not figure out where. Here is where it currently sits.


db.retry.point()
select tpppc211.*
from tpppc211 for update
where .....
selectdo
set_reversal_fields()
db.insert(ttpppc211,db.retry)
commit.transaction()
select table.xxx
from table.xxx
where .....
selectdo
set_split_fields()
db.insert(ttpppc211,db.retry)
commit.transaction()
endselect
tpppc211.loco = ...
db.update(ttpppc211,db.retry)
commit.transaction()
endselect


I have tried with no db.retry and commit for the reversal and split functions, but then the db.update just loops until I get the max retries error. With the retry and commit I get the record not locked error. Without the retry on the inserts, but with the commit I still get no current record. If I take out the last update everything works and runs okay. But I need the last update so I know what records have been processed. Any ideas? I know I am missing something basic with the commit and retry, but am drawing a blank.

Thanks

Mark

mark_h
12th July 2003, 01:54
I forgot to mention that I think I can do it with the first select being an alias, but then instead of using the rcd.ttpppc211 record buffer I would have to use all of the alias fields. Then I could probably go update tpppc211 in another query. Just looking for the easiest way.

Mark

tjbyfield
12th July 2003, 05:23
Mark

I think the inserts reset the pointer. I have had trouble like this and now tend to use alias as safe way out even though it gets messy having to define any of the fields you need to use and bind then to the table fields.

However, you could try moving the update to the beginning of the selectdo, if you can update "in anticipation" and have only one commit at the end of the loop. You could then undo the transaction if you really didn't need the update.

It is the "db.update" that needs the lock/pointer. Another way you could try is to regain the lock with an old fashioned "db.eq" you would have to have not altered the key fields or have restored them befor the "db.eq"

I'm not sure which Baan version your're on but in IVc4 Baan still has lots of the old db calls in programs.

Terry