php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #9869 ODBC - odbc_exec does not seem to work with an Access db
Submitted: 2001-03-20 08:51 UTC Modified: 2001-06-05 17:43 UTC
From: bruceg at garlockprinting dot com Assigned:
Status: Closed Package: ODBC related
PHP Version: 4.0.4pl1 OS: RedHat 6.2
Private report: No CVE-ID: None
View Developer Edit
 [2001-03-20 08:51 UTC] bruceg at garlockprinting dot com 
I am unable to use PHP/Openlink ODBC to get specific rows based on my SELECT statement form a MS Access 97 db.  I can use PHP/Openlink just fine while accessing an Informix db hosted on a SCO box.  I can also use Perl/DBI:DBD:ODBC to get the rows I need from this Access db, so I'm guessing this is a PHP bug.  Here is a snipet of the code I use:

putenv( "ODBCINI=/usr/local/openlink/bin/odbc.ini" );
putenv( "ODBCHOME=/usr/local/openlink" );
putenv( "ODBCINST=/usr/local/openlink/bin/odbcinst.ini");

$conn = odbc_connect("DSN=ink","","", SQL_CUR_USE_ODBC);
$sql = "SELECT DISTINCT * FROM ComponentUse WHERE Code = 'CX145' ";
$cur = odbc_exec($conn, $sql);

// This section of code displayes the tables in the db fine.
$tablelist = odbc_tables($conn);
while (odbc_fetch_row($tablelist)) {
echo odbc_result_all($tablelist);
}

// This section of code does not work - dies with "Driver not capable"
while (odbc_fetch_row($cur)){
$code = odbc_result($cur, "code");
printf ("Code: $code\n");
}
odbc_close($conn);

The code will display the table list just fine, but I get the following error from the odbc_exec statement:

Warning: SQL error: [OpenLink][ODBC][Driver]Driver not capable, SQL state S1C00 in SQLExecDirect in
/home/httpd/html/ink/dispenser/comp_use.php on line 23

Like I said, I can use Perl/DBD just fine to get the rows I want with that select statement, so this must be a PHP bug?

Thanks for any help.  I really would like to write this application in PHP, since I'm not too proficient in Perl.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-03-26 17:05 UTC] kalowsky@php.net 
working on something similar already for some of the other bug reports... guess i can tack this onto the pile as well..
 [2001-03-28 10:55 UTC] ahill@php.net 
Bruce,

What version of the OpenLink drivers are you using?  The problem here is
most likely due to the fact that you're still running Release 3.2 of
OpenLink.  The reason Perl works and PHP doesn't is because PHP 4 opens
select statements on server-side dynamic cursors by default.  OpenLink 3.2
did not handle this functionality as it should have.  You don't really need
this type of cursor, and if you don't want to upgrade OpenLink, we suggest
you disable dynamic cursor functionality in PHP by commenting out all lines
like this:
  #define HAVE_SQL_EXTENDED_FETCH 1
in all the PHP include files for ODBC.  Of course, this assumes the problem
is happening *after* the query has been executed in your code.

Otherwise, an upgrade to OpenLink release 4.0 drivers would be recommended.

On a related note, one thing we had requested from the PHP development
community was the ability to use the "odbc_setoption" function to modify the
ODBC cursor type *before* the preparation of a query.  (I.e. Remove the
necessity to create a $result type object prior to changing the cursor type
of the statement.)  This would help in cases where Preparing or Executing
the query is causing database-specific errors because of the dynamic cursor
type.

Regards,
Stephen
OpenLink Software
http://www.openlinksw.com
 [2001-03-28 11:16 UTC] bruceg at garlockprinting dot com 
I am using 3.2.  I am reluctant to move up to 4.0, since this box uses ODBC to 3 different machines, and I would not want to break anything.  When I find some free time, I'll try 4.0, but 3.2 is working fine right now, other than the problem with MS Access.  Hopefully I can try and recompile with the suggestions, and see if that helps.  I ended up coding that particular project in Perl, since I was under a time constraint.  As soon as I get some free time, I'll port it back to PHP, and submit my results.  

Thank you for looking into this problem.

- Bruce
 [2001-03-28 11:25 UTC] kalowsky@php.net 
considered closed for now.  re-open please if the bugs still exist after your porting and testing please
 [2001-06-05 17:43 UTC] bruceg at garlockprinting dot com 
Once I commented out: 

#define HAVE_SQL_EXTENDED_FETCH 1

All was well using PHP to this ODBC datasource.  Thanks for the information.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 16:01:28 2024 UTC