php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #11 odbc_exec() fails on successful query
Submitted: 1998-01-26 18:58 UTC Modified: 1998-01-27 07:49 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: walton at nordicdms dot com Assigned:
Status: Closed Package: ODBC related
PHP Version: 3.0 Latest CVS OS: WinNT 4.0
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: walton at nordicdms dot com
New email:
PHP Version: OS:

 

 [1998-01-26 18:58 UTC] walton at nordicdms dot com
[Reposted for entry into the nifty new bug database]

We've been calling stored procedures in MS-SQL thusly:

  $result = odbc_exec($conn,"exec sp_asp_dmsGetArtist 303");

That has worked up to and including 3.0b2a.  However in
more recent versions, including 3.0b4-dev, that code has 
produced:

  Warning:  Function SQLExecDirect in testodbc.php3 on line 22
  Warning:  SQL error: [Microsoft][ODBC SQL Server Driver]Cursor type 
            changed, SQL state 01S02 in testodbc.php3 on line 22

According to ODBC docs:

  SQLSTATE:  01S02
  Error:  Option value changed
  Description:  The driver did not support the specified
                value of the vParam argument and
                substituted a similar value. (Function
                returns SQL_SUCCESS_WITH_INFO.)

By comparing the 3.0b2a and 3.0b3-dev unified_odbc.c files,
we've located the probable cause of this error.  In
php3_uodbc_do() on line 763 (in 3.0b3-dev) we see:

  if(SQLSetStmtOption(result->stmt, SQL_CURSOR_TYPE, SQL_CURSOR_DYNAMIC)
     != SQL_SUCCESS){

That function call appears to complete successfully.  Then,
on line 776 we see:

  if((rc = SQLExecDirect(result->stmt, query, SQL_NTS)) != SQL_SUCCESS){

It is this function that appears to generate the error.  My
guess is that our ODBC driver doesn't support SQL_CURSOR_DYNAMIC
and falls back to the default cursor type (which works fine
in 3.0b2a).  The query then completes successfully (according
to SQLTrace), and returns SQL_SUCCESS_WITH_INFO (according to
ODBC doc quote above).

Based on this information, I believe the fix is to replace 
line 776 with:

  rc = SQLExecDirect(result->stmt, query, SQL_NTS);
  if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO) {


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [1998-01-27 07:49 UTC] ssb
This patch submitted and appears in functions/unified_odbc.c
version 1.26.

 [2014-01-01 17:38 UTC] bukka@php.net
Automatic comment on behalf of bukka
Revision: http://git.php.net/?p=pecl/tools/fann.git;a=commit;h=4ca35a885069f8ddd5109cf28c5dec6a4f75e042
Log: Fix #11: Failed build with -Werror=format-security
 [2016-03-07 03:10 UTC] ae@php.net
Automatic comment from SVN on behalf of ae
Revision: http://svn.php.net/viewvc/?view=revision&revision=338684
Log: Merge pull request #11 from fabioluciano/appendices/migration70

Translations by fabioluciano.
 [2017-10-06 16:16 UTC] willfitch@php.net
Automatic comment on behalf of willfitch
Revision: http://git.php.net/?p=pecl/numbers/bitset.git;a=commit;h=37156a024faf153d9b034d3c341a94be2705fd0d
Log: Fix #11
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC