>>>>>That error happens then the datasource for a combo gets closed before the combo is destroyed.
>>>>>
>>>>Right, but in that particular form we set the RowSource to empty string before re-creating the source. But I think I was able to solve this problem by renaming the cursors. Apparently something is not closed properly and therefore causing conflicts but I was not able to trace it.
>>>
>>>It's been ages since I last had that error. Suspend when it happens and just fire up the debugger - check for any form that's still unreleased. Alternately, see which datasession is still dangling - it would belong to the offending form. Most frequently, there's an uncommitted buffer somewhere in that session, so it has closed some of the tables but couldn't close them all, which then left the combo orphaned. Also possibly caused by an unrelated error, if the error handler tries to close the form but can't, and thus causes this.
>>
>>That error dialog doesn't give you an option to suspend.
>
>Then put an assert in the combo's requery (or refresh) to check that the rowsource is still open. Perhaps there you can catch it.

I believe I fixed it already although I used a bit less scientific approach. I decided to make sure the cursors for these 3 combos have unique names so where are no chances they collide with other forms accidentally. I added PO at the end, so, for example, the csrCategory became csrCategoryPO (as these forms are for Purchase Order editing). This seems to resolve the problem, since I am unable to reproduce it now and I was reproducing it consistently before (the client figured out the steps to reproduce since prior to that it was an intermittent problem).