Synchronizing stored procedures

[Ralph Cramden]

I'm writing a VB6 app which calls several stored procedures on my SQL
Server DB.

The first stored procedure must complete its inserts before the second
stored procedure can query the modified table for its results. My
problem is that
the second stored procedure occasionally returns a different result
set, acting as if the first stored procedure didn't complete (or
didn't run).

So how do I ensure (or test/poll?) that the first stored procedure
runs to completion before returning control back to my VB app?

Thanks in advance,

Ralph

[Ross Presser]

cr*******@hotma il.com (Ralph Cramden) wrote in
news:e2******** *************** ***@posting.goo gle.com:

I'm writing a VB6 app which calls several stored procedures on my SQL
Server DB.

The first stored procedure must complete its inserts before the second
stored procedure can query the modified table for its results. My
problem is that
the second stored procedure occasionally returns a different result
set, acting as if the first stored procedure didn't complete (or
didn't run).

So how do I ensure (or test/poll?) that the first stored procedure
runs to completion before returning control back to my VB app?

Thanks in advance,

Ralph

Might it make sense to combine your procedures? Or perhaps create a third
stored procedure that calls the first then the second in sequence?

[Erland Sommarskog]

[posted and mailed, please reply in news]

Ralph Cramden (cr*******@hotm ail.com) writes:

I'm writing a VB6 app which calls several stored procedures on my SQL
Server DB.

The first stored procedure must complete its inserts before the second
stored procedure can query the modified table for its results. My
problem is that
the second stored procedure occasionally returns a different result
set, acting as if the first stored procedure didn't complete (or
didn't run).

So how do I ensure (or test/poll?) that the first stored procedure
runs to completion before returning control back to my VB app?

Do you call the procedures from different threads or asynchronously? That
would be the only way for the second procedure before the first have
completed. In both cases, you would need synchronization in the client
code.

I suspect that your real problem is something else. That is, you are calling
the two procedures sequentially from the same thread, but there is some
flaw of logic, causing the incorrect result. It could also be that the
first procedure runs into an error condition, which you fail to handle
properly in the application code.

That is, if you are calling stored procedures in the plain vanilla way,
you don't have to worry about synchronization , since all calls to SQL
Server are synchronous.

--
Erland Sommarskog, SQL Server MVP, es****@sommarsk og.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[Ralph Cramden]

My fear is that I'm calling the stored procedures asynchronously
and I don't want to.

The Project properties dialog box shows that the app is a standard
EXE project type (threading model is grayed out (so I'm assuming
a single thread)).

The SQL server though is a multiple CPU(4) platform would that
make a difference?

How would I synchronize the client code?

Erland Sommarskog <es****@sommars kog.se> wrote in message news:<Xn******* *************** @127.0.0.1>...

[posted and mailed, please reply in news] Do you call the procedures from different threads or asynchronously? That
would be the only way for the second procedure before the first have
completed. In both cases, you would need synchronization in the client
code.

I suspect that your real problem is something else. That is, you are calling
the two procedures sequentially from the same thread, but there is some
flaw of logic, causing the incorrect result. It could also be that the
first procedure runs into an error condition, which you fail to handle
properly in the application code.

That is, if you are calling stored procedures in the plain vanilla way,
you don't have to worry about synchronization , since all calls to SQL
Server are synchronous.

[Erland Sommarskog]

Ralph Cramden (cr*******@hotm ail.com) writes:

My fear is that I'm calling the stored procedures asynchronously
and I don't want to.
I don't want to scorn you, but if you don't know if you are writing
a synchronous application or not, you are a very confused VB programmer.
(And if you really want certainty, you would have to ask in a Visual
Basic newsgroup; that's not really an SQL Server question.)
The SQL server though is a multiple CPU(4) platform would that
make a difference?
That has nothing to do with it.
How would I synchronize the client code?

It does not sound like you would need to. If your code looks like this:

Set cmd = new ADODB.Command
cmd.ActiveConne ction = cnn
cmd.CommandType = adCmdStoredProc
cmd.CommandText = my_first_proc
cmd.Execute
Set cmd = Nothing
Set cmd = new ADODB.Command
cmd.ActiveConne ction = cnn
cmd.CommandType = adCmdStoredProc
cmd.CommandText = my_second_proc
cmd.Execute
Set cmd = Nothing

There is nothing to synchronize. cmd.Execute blocks until SQL Server
has completed execution.

If you are using separate threads, or the synchronous capabilities of
ADO and issue the commands on two separate connection, you have indeed
quite a few interesting problems. Then again, that's not a path you
should not take if you don't know what you are doing.

--
Erland Sommarskog, SQL Server MVP, es****@sommarsk og.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[Ryan]

A DTS package would do this for you really easily.

[Erland Sommarskog]

Ryan (ry********@hot mail.com) writes:

A DTS package would do this for you really easily.

Eh? I don't know much about DTS, but there is actually one thing I've
used DTS for, and that is to test the multi-threading capabilities of a
Perl module for SQL Server access. Because in DTS, things really happens
in parallel. What implications that has for what DTS is used for, I don't
really know, but I have noticed that you can arrange tasks, so that task B
does not start before task A has completed, but you can also arrange for
A and B to be in parallel if you like.

Now, whether this has any relevance for Ralph's question, I don't know,
but my guess it has not.
--
Erland Sommarskog, SQL Server MVP, es****@sommarsk og.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[Ryan]

Erland,

My understanding of the problem was that there was a need to run two
SP's. The second SP needs to run after the first has completed. Doing
this in a series of stored procedures or an SP that runs both could
force the execution plan to determine that it's better to run the second
SP before the first (hence the problem).

I was suggesting the DTS as an option as you can make a stored procedure
'wait' until the sucess of a prior SP. In it's most simplistic terms,
this should solve the problem. It is really good at running things in
parallel as well, but this may work in this case.

I would have tried creating a small DTS package that runs the second SP
on success of the first task. This would take a matter of minutes to do
and would not require changing the SP's.

I may well be wrong, but given that it would take a short time to set up
and test, I felt it might be worth a look. Hopefully I have not missed
the point.

Ryan

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Erland Sommarskog]

Ryan (an*******@devd ex.com) writes:

My understanding of the problem was that there was a need to run two
SP's. The second SP needs to run after the first has completed. Doing
this in a series of stored procedures or an SP that runs both could
force the execution plan to determine that it's better to run the second
SP before the first (hence the problem).

I was suggesting the DTS as an option as you can make a stored procedure
'wait' until the sucess of a prior SP. In it's most simplistic terms,
this should solve the problem. It is really good at running things in
parallel as well, but this may work in this case.

That's correct, that DTS gives you a synchronization mechanism. (Hey,
that is as much I know about DTS.)

However, you can achieve the same with:

Set cmd = new ADODB.Command
cmd.ActiveConne ction = cnn
cmd.CommandType = adCmdStoredProc
cmd.CommandText = my_first_proc
cmd.Execute
Set cmd = Nothing
Set cmd = new ADODB.Command
cmd.ActiveConne ction = cnn
cmd.CommandType = adCmdStoredProc
cmd.CommandText = my_second_proc
cmd.Execute
Set cmd = Nothing

Throwing in DTS in a VB app to solve something which works out of the
box in VB appears to be a huge overkill to me.

(And if your VB app is multi-threaded or you use asynchronous calls,
DTS would still be a huge overkill, give that implmentation of
thread-synchronization or handling of asynchronous calls is not really
rocket science, even if it goes beyond what a plain-vanilla does.)
--
Erland Sommarskog, SQL Server MVP, es****@sommarsk og.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[Ryan]

Fair enough :-)

Erland Sommarskog <es****@sommars kog.se> wrote in message news:<Xn******* *************** @127.0.0.1>...

Ryan (an*******@devd ex.com) writes:

My understanding of the problem was that there was a need to run two
SP's. The second SP needs to run after the first has completed. Doing
this in a series of stored procedures or an SP that runs both could
force the execution plan to determine that it's better to run the second
SP before the first (hence the problem).

I was suggesting the DTS as an option as you can make a stored procedure
'wait' until the sucess of a prior SP. In it's most simplistic terms,
this should solve the problem. It is really good at running things in
parallel as well, but this may work in this case.

That's correct, that DTS gives you a synchronization mechanism. (Hey,
that is as much I know about DTS.)

However, you can achieve the same with:

Set cmd = new ADODB.Command
cmd.ActiveConne ction = cnn
cmd.CommandType = adCmdStoredProc
cmd.CommandText = my_first_proc
cmd.Execute
Set cmd = Nothing
Set cmd = new ADODB.Command
cmd.ActiveConne ction = cnn
cmd.CommandType = adCmdStoredProc
cmd.CommandText = my_second_proc
cmd.Execute
Set cmd = Nothing

Throwing in DTS in a VB app to solve something which works out of the
box in VB appears to be a huge overkill to me.

(And if your VB app is multi-threaded or you use asynchronous calls,
DTS would still be a huge overkill, give that implmentation of
thread-synchronization or handling of asynchronous calls is not really
rocket science, even if it goes beyond what a plain-vanilla does.)