>>A few more thoughts:
>>
>>- when a user "copies" a quote, the current procedure puts the records to be added into a view and then posts the records as a batch
>
>since introduction of CursorAdapter I strive to base all data access on it. Sometimes rewrite to it makes sense even from view based code - even if hard to sell to paying customer.

I am going to suggest to this customer that they allow me to start rewriting to use CursorAdapter going forward to try to standardize their data access so that when they decide to upsize to SQLServer (or Postrges etc), they will be better prepared for it. Thanks for suggesting that as well as it reinforces what I had planned to tell them.


>>- in the past under older code, I instead added these records via doing a SCATTER from the source record and then an APPEND BLANK into the target table followed by a GATHER; I can't say this worked foolproof either
>>

>>- in my mind, there should be no difference between a view posting new records and doing so via APPEND BLANK or INSERT INTO - lock the header, add in the rows, write in the data, unlock the header etc
>> ---> is there a difference?
>
>Append BLANK always introduces chances of candidate/PK conflicts in multiuser. Key routines IMO best handled encapsulated / separate from pure "toDisk" handling and called in advance. But errors should point directly to cause...

The key generation is done by a centralized routine so it has not been a problem - only problem comes when I am manually testing things out and circumvent that routine and I cause a problem - but that's my fault :-)



>>- there is no buffering on the target table...would it work better if there was? Again, I don't see how this would make a difference but am just looking for ideas?
>
>You could handle some errors from flaky network or Win temporarily messing up subst/net use drive names when employing table buffered data. But those errors should produce clear error msg, so probably not your current problem.