Win has asked for the wisdom of the Perl Monks concerning the following question:

I have a series of Stored Procedures in an MS SQL database. These stored procedures are executed in turn without any problems when executed from within SQL Query Analyzer. Like so:
EXEC Reception 'DSR', 'EuropeanStandard', 'Intentional self-harm', 1, +'MF', 1, 'nul', 'nul', 'nul', 'nul', 'nul', 'nul', 'nul', 'nul', 'nul +', 'nul', 'nul', 'nul', 0, 1990, 2002, 0, 74, 'Community', 'Community + name', 'Town name', 3, 'DKaReTinnvzEHNPbskwFqukPioqrDwJrkDBJ'

But, when I run the same EXEC statement from a Perl program via an ODBC connection, the process starts to proceed as normal, but then stalls half way through. I really have no idea where to start looking. The process was working fine previously with Perl activation and I have only made small changes to the SPROC code since then. I have pin pointed where the stalling occurs and cannot find an error with the T-SQL code. Anyway, as I have said, it works well when not activated by the perl program. The Perl program that does the activation is as follows. Does anyone have any ideas what could be going wrong? NB. I don't think that the problem is with the Perl code. That has not changed since it was working before.

#! perl -w scipt use strict; use warnings; use DBI; use DBD::ODBC; use File::Copy; #use vars qw(@row_) = (); my ($data_source, $database, $user_id, $password) = qw(ip_address data +base_name user_name password ); my $conn_string = "driver={SQL Server}; Server=$data_source; Database= +$database; Trusted_Connection=yes"; my $dbh = DBI->connect( "DBI:ODBC:$conn_string" ) or die $DBI::errstr; my $inputfile = $ARGV[0]; my $outputfile = $ARGV[1]; my $Request_id; my $Variable_number; my $Variable; my $Choice; my @VARIABLE; my @CHOICE; my $Command; my $Return_results; my $SPROC; my $unique; my $elements_in_array; my $Component_number_old = 1; my $Component_number = 1; #my $flat_file = "Flat_file_test_C.txt"; my $flat_file = $inputfile; open (FLAT_FILE, "<$flat_file"); while (<FLAT_FILE>){ chomp; s/"//g; # This " is generated by excel when there is a comma in th +e line that is printed by excel $Component_number_old = $Component_number; if ($_ =~ /^$/) { last; } elsif ($_ =~ /SPROC\sName\:\s([a-z|A-Z|0-9|_]{1,100})/){ print "Hi_A\n"; $SPROC = $1; } elsif ($_ =~ /^\*(.{36});(\d{1,5});(\d{1,5});([a-z|A-Z|0-9|_]{1,50}) +;(.{1,150})/){ print "$_\n"; push (@VARIABLE, $Variable); push (@CHOICE, $Choice); print "Hi_B\n"; $unique = $1; $Component_number = $2; $elements_in_array = $3; $Variable = $4; $Choice = $5; } elsif ($_ =~ /^\*(.{36})\;(\d{1,5})\;(\d{1,5})\;([a-z|A-Z|0-9|_]{1,5 +0})\;$/){ print "$_\n"; push (@VARIABLE, $Variable); push (@CHOICE, $Choice); print "Hi_B\n"; $unique = $1; $Component_number = $2; $elements_in_array = $3; $Variable = $4; $Choice = "NULL"; } if ($_ =~ /^\sEND/){ print "Hi_E\n"; push (@VARIABLE, $Variable); push (@CHOICE, $Choice); $Command = join(' ', 'EXEC', $SPROC, join(', ', @CHOICE[1 .. $elements_in_array])) . ';'; my $Request_id = $CHOICE[$elements_in_array]; print "$Command\n"; Got_Command($Command, $Request_id, $outputfile); undef @CHOICE; my @CHOICE; } } close FLAT_FILE; sub Got_Command { my($Command_B,$Request_id_B, $outputfile_B) = @_; open (OUTPUT_FILE, ">>", $outputfile_B) or die "Unable to open $outputfile: $^E\n"; print "Hi_F\n"; print "$outputfile\n"; print "$Command_B\n"; my $sthB_A = $dbh->do($Command_B) or die "Couldn't do query: ".$dbh +->errstr; my $Return_results = "Select DISTINCT Colls FROM Database"; print "$Return_results"; my $sth_C = $dbh->prepare($Return_results) or die "Couldn't prepare +query: ".$dbh->errstr; $sth_C->execute() or die "Couldn't execute query: ".$sth_C->errstr; while (my @row = $sth_C->fetchrow_array) { print "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~\n"; print join("\t", @row); print "\n"; print "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~\n"; print OUTPUT_FILE join("\t", @row); print OUTPUT_FILE "\n"; undef @row; } }

Replies are listed 'Best First'.
Re: Perl activation of MS SQL SPROCS
by tphyahoo (Vicar) on May 10, 2005 at 08:49 UTC
    You wrote "That has not changed since it was working before." Well, what has changed? The sprocs, right? What has changed about them? It was kind of hard to follow what you meant here. Why should changing sprocs affect perl code, when the perl code wasn't calling the sprocs in the first place?

    Perhaps you could post the sprocs, which are working, along with the code which is not working.

    And post less code, and comment it to explain where it dies out.

    I've had this kind of thing before and it can be really frustrating. The root of the evil to me seems the difficulty of version controlling databases. The closest thing you could have is restore from backup, and then compare old with new. But what a pain. Good luck.

      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.

        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.
        A reply falls below the community's threshold of quality. You may see it by logging in.
        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.

      I am wondering whether there is something about the ODBC connection that is altering the behaviour of the database, causing it to fail sometimes, depending on what the SPROCS are doing. There are about 20 SPROCS and about 15-30 tables are created in the process, depending on the state of the database.