I suspect that FK caused the problem because the new connection is waiting for the other connection to commit and release its locks so that the new conn. can check the inserted FK values for validity.

This ought to happen only with trans. iso. level set to 'repeatable read' or higher - UNLESS - ADO is holding locks, maybe by using adLockPessimistic server-side cursors.

I don't agree with your assessment of how the second connection is created, though - I've never encountered ADO 'branching' the connection object to use two separate SPIDs. This would be undocumented and bizarre behaviour - and as you have seen, there is a good reason for it's not doing so.

But if as your code shows, the you specify the same connection in your rs.Open call, I don't see how the rst could end up on a different connection...any ideas, anyone?