We have a report that queries our MSSQL server via perl. After running the report a few times, its like the ODBC driver completely crashes. The SQL server is still running on the Windows server - our business system works with no issues. The linux server running the reports just stops working alltogether with the SQL server. Any ideas on why this is or how to fix/isolate the issue?

Any help is greatly appreciated. Thanks.

Not much we can tell you, without seeing the script. Could be as simple as a bug somewhere in it, a mishandled connection, etc. And where did you get the MSSQL 'driver' you mention? If you're talking about the DBD::ODBC driver from CPAN (the logical choice), you should also know that MSSQL doesn't behave correctly (huge surprise there), under certain conditions.

Things like performing a query that doesn't return results, or trying to access a data field that is NULL, can cause problems. Also, you don't mention whether you have any XML data types in what you're reading, as that, too, can cause a problem with some older versions of DBD::ODBC

The CPAN page on that module has lots of information and potential gotchas/problems with MSSQL:
http://search.cpan.org/~mjevans/DBD-ODBC-1.48/ODBC.pm

Honestly, if this was my project, and I only needed reports once a day/week/whatever, I'd set up a scheduled job on the MS server to export the database to a .csv file, and a cron job on the Linux server to import that file into a MySQL database, and enjoy better speed, stability, and ease of coding. It's two extra steps, but the upside is that you'd have a hot export of the MSSQL database if things go pear shaped, and you could even test migrating your other pieces of software over to MySQL...if you felt like going down the Linux-only road.

I'm using the CPAN driver DBD::ODBC.

I actually like the idea of putting the data into MySQL a lot. We only need to run this specific report once a month or so.

Well, I can only offer the advice of that being what I'd do. It would offer a good deal of stability to the reports, and give you other benefits as well, too. Since that data would be 'live' (but NOT the production database), you could run reports more often, hook things into a web interface for graphing and/or running custom reports ad-hoc, etc. And NOTHING you do on that database would affect production.

That said, if you want your other perl program to function better/at all, I'd check the data types and queries the next time it fails. Run the queries manually against the DB, and see what it pulls out. You might be able to write some error handling into your program to catch such exceptions.