>>Had a strange case... the scenario goes like this:
>>
>>

if not seek(...)
>>    insert into ... (short field list, just keys) values (...)
>>    tableupdate()
>>endif
>>...
>>replace {four more fields}
>>tableupdate()

>>
>>This was a fast job so I didn't really check the result of each tableupdate(); this is on cursoradapters, BTW. The weird thing is that in cases where the record was freshly inserted, the second tableupdate() didn't work. The quick and dirty solution was to run this twice, which worked so I didn't lose too much time on it (it had about 70000 records to create/update), but I'm just curious as to why would this happen at all.
>>
>>Did anyone have a horse of this color?
>
>You could check the return value *and* add the optional cErrorArray, so you can log it in a text log file.
>
>What happens if you only use ONE TableUpdate() at the end, and not in the middle?

Yes, that would be the obvious fix.

I don't really need a fix - this bit of code was a one-time conversion of a list from a .csv file, and now it's done and forgotten. I was just curious about the causes.

So, to answer the others - no, I didn't check the return value from either tableupdate(), didn't catch errors, didn't try to fudge the code to make it work right. Had just enough time to see that it works, at least the second time - and then left someone else to run it the second time 'cause I had to drive to the airport.

I'm interested in the cause for the sake of such things in the future. This was copied from another similar routine, just replaced the field names and didn't touch the logic much, so I may forget this and copy from the same place some time next year. And when it comes to that I'd like to know what's wrong in advance, and set it right before I start pulling the remainders of my hair :).