Re^2: Perl activation of MS SQL SPROCS

What do you mean by fail? A hangup, everything just slows down and blah? Or a righteous error message?

If it's just slowing down and blah, maybe you're doing something that creates conflicts, like doing selects at the same time that you're doing updates/inserts, or like that. Maybe the evil is more evil when done through perl as through odbc. Shot in the dark.

Comment on Re^2: Perl activation of MS SQL SPROCS

Replies are listed 'Best First'.
Re^3: Perl activation of MS SQL SPROCS by Win (Novice) on May 10, 2005 at 09:43 UTC
Yes a hang-up. I don't really understand how that can happen because surely one SPROC finishes before the other one can start. Maybe I need to put a sleep command into my Perl program to stop a series of commands from overrunning each other.	[reply]
Re^4: Perl activation of MS SQL SPROCS by tphyahoo (Vicar) on May 10, 2005 at 09:46 UTC
Yes, maybe. Maybe running whatever you're doing through sprocs works better, because it's being managed through the rdbms, and the rdbms knows to wait until the sproc finishes before going on to whatever the next thing is. But, perl doesn't realize to wait. (Still shooting in the dark of course.)	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.
Re^3: Perl activation of MS SQL SPROCS by Win (Novice) on May 11, 2005 at 16:37 UTC
For the record. I have got over the problem that I had by implementing the following recommendation that I found on a web site: 10. Include SET NOCOUNT ON statement into your stored procedures to stop the message indicating the number of rows affected by a T-SQL statement. This can reduce network traffic, as your client will not receive the message indicating the number of rows affected by a T-SQL statement.	[reply]