|Do you know where your variables are?|
Comment onby gods
|on Feb 11, 2000 at 00:06 UTC||Need Help??|
Here is the Solution:
Martin Evans on the dbi-user mailing list was able to finally find the source of this error, here is the text of his reply:
I analysed your log and did the same thing in ODBCTest which used to come with MDAC and it fails in the same way: SQLPrepare(print 's' select count(*) from table print 'e') SQLNumResultCols() returns SQL_ERROR and invalid cursor state. so, I'm afraid, there is no bug in DBD::ODBC and the problem is in the MS SQL Server driver. Interestingly, our ODBC-ODBC Bridge makes you code almost work because it inserts a call to SQLNumParams between the SQLPrepare and the SQLNumResultCols and that puts the MS SQL Server Driver into a different state. I say "almost" because it does appear to hightlight another bug in the MS SQL Server driver later on where SQLMoreResults returns SQL_NO_DATA but a later call to SQLNumResultCols returns 1 column and this persuades DBD::ODBC there is a column and it fails on a call to SQLDescribeCol (because SQLNumResultCols lied and there is no result-set). Your only choice is to take the prints out.
I ended up building DBI 1.45 and DBD::ODBC 1.11 on my machine.
I was still able to achieve the desired result by using a suggestion our DBA made of substituting a SELECT everywhere there is a PRINT and that seems to work nicely. For statements that return multiple result sets I ended up using the following:
Thanks to all who responded.