L
Laura Stern
Guest
See the kbase that I referenced. Basically it says: As part of ending a transaction (not a sub-transaction), the AVM goes through any buffer that is still in memory and tries to validate it if it hasn't been written out to the db. The temp-table record that caused the initial 132 error is in a persistent procedure which is still in memory, so every time some code that ends a transaction is run, it will cause the AVM to try to validate that record, and it will fail because of the index conflict. Even if it's a transaction that has nothing to do with that temp-table, the AVM will still handle it the same way. Does that seem to match your circumstance?
Continue reading...
Continue reading...