We need to create several SQL reports, each of which depends upon the results of the previous report. All queries are in the following form: Select 1, Report 1, Select 2 from Select 1, Report 2, Select 3 from Select 2, Report 3, ...and so on to... Report N.
Right now "N" separate SQL queries are used to generate the complete set of reports. Every query contains the SQL code for all previous queries - which results in Report 1 being done "N" times, Report 2 being done "N - 1" times, etc. The resulting mindless repetition of the same select statements in multiple reports is causing performance issues.
How do we export the intermediate reports, ideally as .csv files, as they are generated by report "N", thereby eliminating the need for all other reports?
Some complicating factors that are specific to our case:
- A turnkey approach must be used, making any approach that uses any form of manual intervention unacceptable. Plain text output is required.
- OBDC (specifically Python's pyobdc package) is used to pass the SQL queries to the SQL Server (as a cursor). Python uses the results to create the report as a .csv file.
- Stored SQL procedures are prohibited but the existing SQL code does use temporary tables.
- Results must be written to my (client) machine. Our IM department might allow us to use a temporary folder on their server.
- It seems pyobdc can only accept one result set (hence the need for "N" queries). Ensuring the proper result set gets passed back requires that the SQL query begin with "SET NOCOUNT ON" (as advised by the pyobdc mailing list). I know of no other way to return/select the right result set from the multiple result sets returned by SQL. I have tried a pyobdc method (cursor.nextset) to skip over result sets but nothing was returned.
- I considered passing the results of report "n - 1" into report "N" - but the quantity of data involved probably makes this impractical.
- The Python (3.2.2) & SQL code is well proven, production code. Changing languages is not a practical option. Changing OBDC packages is possible but unlikely (a very strong case would have to be made and the other OBDC package must be easily portable across platforms and also be able to connect to Microsoft SQL Server 2008 Management Studio).
- Eclipse (Helios) with the pydev plugin is being used to launch the Python application that launches the SQL queries.
- The client O/S is XP Pro Sp 3, the server is believed to be the same. The company is planning to migrate our machines to Windows 7/8 "sometime soon" so portability to that O/S is a factor.