default result set semantics

When an ADO command does not exhaust the default result set and a second
command is executed, the sqloledb provider automatically spawns a new sessio
n
to execute the second command (using the default result set). My question is
since command2 was definied on the connection (and prepared = true), should
one be allowed to rebind a paramter on command2 and execute again? Doing so
results in the following error -
"Multiple-step OLD DB operator generated errors. Check each OLE DB status
value, if available. No work was done."
pseudo code example:
cmd1.execute
while not rs1.eof
obtain row value, bind into cmd2
cmd2.execute
First execute works, second iteration fails.
The solution is to shutdown cmd2 within the loop and recreate the command
for each execution.
Is this the expected behavior because of the inconsistent state for the
command (having been spawned to a new session)?
I know 2005 solves this issues w/ MARS.
Thanks.Correct. MARS in yukon is designed to solve this.
[url]http://msdn.microsoft.com/library/en-us/dnsql90/html/MARSinSQL05.asp?frame=true[/u
rl]
-oj
"Thomas Brown" <ThomasBrown@.discussions.microsoft.com> wrote in message
news:B495E631-3D88-4880-B678-6E7F6DF9749C@.microsoft.com...
> When an ADO command does not exhaust the default result set and a second
> command is executed, the sqloledb provider automatically spawns a new
> session
> to execute the second command (using the default result set). My question
> is
> since command2 was definied on the connection (and prepared = true),
> should
> one be allowed to rebind a paramter on command2 and execute again? Doing
> so
> results in the following error -
> "Multiple-step OLD DB operator generated errors. Check each OLE DB status
> value, if available. No work was done."
> pseudo code example:
> cmd1.execute
> while not rs1.eof
> obtain row value, bind into cmd2
> cmd2.execute
> First execute works, second iteration fails.
> The solution is to shutdown cmd2 within the loop and recreate the command
> for each execution.
> Is this the expected behavior because of the inconsistent state for the
> command (having been spawned to a new session)?
> I know 2005 solves this issues w/ MARS.
> Thanks.
>