Paliss
28th March 2002, 10:53
Error 206 table is not locked for main table of session appears when I try delete range of records.
Only first record is deleted.
Section after delete looks as below shown.
after.delete:
select table.*
from table for update
where table
selectdo
table.xx = uu
db.update (table, db.retry)
endselect
commit.transaction()
For all records marked for delete is update sucesfully done.
The same situation is in section after.rewrite (update) for more than 1 record
For after.write (insert) more records is all OK.
When I function commit.transaction() remove from program than program hangs with error cannot continue transaction is on
Can anybody help me?
Thanks
Paliss
evesely
28th March 2002, 15:58
commit.transaction() is part of the standard program. Therefore, it should not generally be placed in a section that is kicked off by a standard insert/update/delete action. So, taking it out of the after.delete solves one problem.
As for the "transaction is on" error, what is the relationship between the table your are trying to update in the after.delete section and the session's main table? "Transaction is on" means that you had a pending (i.e., uncommitted and unaborted)transaction when you tried (again) to modify that same record.
Perhaps you can explain exactly what you are trying to accomplish. That might help encourage more comments.
Paliss
28th March 2002, 17:31
The problem is following.
I have table BOX, where is box, weight and so on.
Next table is BOX-ROW where is weight of row etc.
Next table is TDSLS045 delivery , where I use field dqua-delivery amount and new field pack.c packed amount.
When I add/change/delete row of box I have to change table tdsls045 - pack.c - it depends on action.
I must recalculate weight of box from row of box.
All these upadates I havo to do for every row.
Therefore I do updates in sections
after.delete, after.write and after.rewrite
I hope that I explained this enough
Paliss
evesely
28th March 2002, 20:31
I guess I still don't understand the relationships between the tables. Is there a one-to-many relationship between BOX-ROW and BOX. How do these relate to tdsls045 (one delivery to one or more BOXes)? Which table has the type 3 form? I suppose listing the indices would help.
Sorry if I'm being dense.
Paliss
29th March 2002, 10:34
One BOX can have several ROWS of BOX.
One ROW have one DELIVERY (tdsls045).
But one DELIEVERY can be splited between several ROWS.
relations between table
BOX 1:N ROW of BOX
ROWS of BOX N:1 DELIVERY
I attach table stucture of tables BOX and ROWS of BOX
The main table of session and form 3 is table ROWS of BOX (tdsls983)
evesely
29th March 2002, 16:12
OK, I think I have an idea. If you happen to select more than one BOX-ROW that is tied to the same delivery, then you end up trying to perform multiple updates on the same tdsls045 record before reaching the standard program's commit. Your original effort with the commit.transaction would have solved this. However, it interfered with other standard program actions.
There are a few different ways to get around this. One way would be to create arrays to hold the key values (orno, pono, sern) of the affected tdsls045 record as well as the impact on the pack.c field for that delivery. Then, instead of doing the update in the after.delete, you would fill or update the array values. You could then do the updates (based on the arrays) to tdsls045 in the choice.update.db/after.choice section or in the after.update.db.commit section.
I hope this is clear and helps.
Paliss
29th March 2002, 16:19
Thank for your advice.
I'll try it.
Thanks
Paliss
Dwallace
4th April 2002, 19:25
What about the "occ" commands? Would these work in this situation - like 'do.occ.without.update' or 'do.all.occ'?
I don't use these often - and really don't understand them. I see them used in Maintain Receipts, tdpur4120 a lot.
Denise