Hello, Fred

One way is to use the tlForce parameter of kBizObj.Save() -- voila... no conflict. Of course, that means that the last update wins, but there may be scenarios where that's okay.

Otherwise, we've had success by trapping these errors at the kBizObj level. We added a property to determine whether the object should display errors and test for that in kBizObj.ErrorUpdateConflict() before the "Another user..." message is displayed.

We also check for ERROR_UPDATE_CONFLICT and ERROR_MULTI_UPDATE_CONFLICT in kBizObj.HandlError() and add the code to kBizObj's error array.

Now, when a record doesn't save, we can check the error array for one of these error codes and decide what we want to do in a hopefully intelligent manner.

For our batch processes, we typically just requery. That may not be suitable for UI data entry, though, since Requery() squashes everything the user just entered. In that situation, you could always SCATTER, then Requery(), then GATHER the appropriate fields back.

Hope that helps,
---J


>We need to use a command button to run a bit of optimizing code on the cursor of a business object. It changes some dates as it turns out.
>
>1. How can I not get user conflict messages on the record currently being viewed by the user?
>
>2. How can I commit the changes to the cursor so that the underlying table is updated and the view is requeried, again, while not getting any conflict or 'another user has updated this record' type messages.
>
>3. We need to understand the logic flow of the "CBizObjMaintenanceForm Class" when the view is requeried and the record currently pointed at in the grid is changed.
>
>Any help will be gratefully received
>
>Fred