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

This question was moved from Categorized Questions and Answers by Q&AEditors.
Please do not vote for this node. It will affect the wrong user. Thank You.

I had been trying to get a "native" connection to MS SQL 7 via freetds, but it caused me much grief. Instead I went with an ODBC connection using the openlinksw.com available drivers. This is fine and dandy.

My true problem lies hidden deep within the error_log now.

When I run particular fetchrow_hashref (yeah, yeah, I know about problems with it so I don't wanna hear use arrayref or array, I wanna hear answers to MY question. I have also had the same problem with fetchrow_array at times anyway.) it ends up giving this error:

DBD::ODBC::st_fetchrow_hashref failed: [OpenLink][ODBC][Driver]Function sequence error (SQL-S1010)(DBD: st_fetch/SQLFetch err=-1) at /path/to/filename line <i>n</i>

So, my fellow monks, I wish to ask not why I should use fetchrow_array instead of fetchrow_hashref. That information is easily obtained.

My real question is, why does the fetch itself fail? As stated above, I've seen this problem with all types of fetchrow.

I'm confused about what the Function sequence error is. During my testing, I've run this through 'perl -d' and can give you a final piece of information. It does fetch at least once in all cases. It may even fetch more than once in some cases. But it does fail after a subsequent number of fetches.

Thanks

Replies are listed 'Best First'.
RE: DBD::ODBC problem.
by barndoor (Pilgrim) on Aug 09, 2000 at 13:27 UTC
    A known issue that affected SQLServer 6.5 (and I'm guessing 7.0) is that if you open a cursor using a prepare/execute and start reading through it, if you perform a commit or rollback and then try to continue reading from the cursor (perform another fetchrow) you will get the error you describe. I.E. The cursor is closed by the commit/rollback.
    I don't know if this is your problem but it's worth checking.
[reply]

      I have no MS SQL Server 7.0 available to test this, but the MS SQL Server 7.0 is a complete rewrite, as Microsoft does not use the Sybase codebase anymore. So I'd assume a lot of differences between 6.5 and 7.0.

[reply]
        There is a service patch available that allows backwards compatibility (read allows old Sybase connection libs to be used). It's been mentioned here before, I believe, and it's recommended by Michael Peppler in order to work with DBD::Sybase. I'm waiting for his reply on the dbi-users mailing list about my other problems with that. Looks like I found a project to join. :) ALL HAIL BRAK!!!
[reply]
Re: DBD::ODBC problem.
by agoth (Chaplain) on Aug 09, 2000 at 12:15 UTC
    A few Q's, not that they might make any difference:
    1. Which versions of DBI and DBD::ODBC are you using?
    2. Are you on NT / Win**?
    3. Is the database on the same machine as Perl?
[reply]
      1. DBI 1.13 && DBD::ODBC 0.28
      2. Linux 2.2.12-20 (RedHat 6.2) & Apache 1.3.12 for the webserver
      3. The MS-SQL 7.0 database is on a WinNT 4.0 Server.

      I'm using the Linux ODBC Driver manager and Driver from OpenLink. Also, I'm using the request broker from them on the NT Server. ALL HAIL BRAK!!!

[reply]
        Arse.
        I have SQL Server on NT with a perl test script which I was about to have a go on to check if i had the same problems as you but I seem to have broken the database somehow. Cant even get it started.
        Sorry to be of no help whatsoever. :-)
[reply]

Back to Seekers of Perl Wisdom