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

go to bug id or search bugs for

Bug #73191 "SQLColAttribute can't handle SQL_DESC_OCTET_LENGTH" with Foxpro
Submitted: 2016-09-28 06:43 UTC Modified: 2016-10-04 02:59 UTC
From: eion at robbmob dot com Assigned: ab (profile)
Status: Not a bug Package: ODBC related
PHP Version: 7.0.11 OS: Windows
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
45 - 4 = ?
Subscribe to this entry?

 
 [2016-09-28 06:43 UTC] eion at robbmob dot com 
Description:
------------
Every query with odbc_exec() that returns a string is outputting a PHP Warning of "SQLColAttribute can't handle SQL_DESC_OCTET_LENGTH" when using the Foxpro driver.

The full error is 
[28-Sep-2016 19:15:10 Pacific/Auckland] PHP Warning:  odbc_exec(): SQLColAttribute can't handle SQL_DESC_OCTET_LENGTH: [S1091] [Microsoft][ODBC Visual FoxPro Driver]Descriptor type out of range in test.php on line 2

Looking at https://github.com/php/php-src/blob/master/ext/odbc/php_odbc.c#L1018

php_error_docref(NULL, E_WARNING, "SQLColAttribute can't handle SQL_DESC_OCTET_LENGTH: [%s] %s", state, errtxt);

It appears that this warning should actually be a notice, or have some way of blocking this message.  This warning was added in http://git.php.net/?p=php-src.git;a=commit;h=268eb1999b1598a2a1a875c5f0172d5b615811ac

Test script:
---------------
<?php
$a = odbc_connect('Foxpro', '', '');
odbc_exec($a, "SELECT foo FROM bar");

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-09-28 16:00 UTC] cmb@php.net
-Assigned To: +Assigned To: ab
 [2016-09-28 16:00 UTC] cmb@php.net 
That appears to be a bug in the Microsoft ODBC Visual FoxPro
driver (BTW, which version do you use?) Apparently, the driver
claims ODBC 3.0 compatibility, but doesn't know about
SQL_DESC_OCTET_LENGTH.

Not sure if we should do something here, besides reporting the
issue to Microsoft.

Anatol, what do you think?
 [2016-09-28 19:04 UTC] ab@php.net
-Status: Assigned +Status: Not a bug
 [2016-09-28 19:04 UTC] ab@php.net 
Thanks for checking, Christoph. Yeah, it looks like not a PHP issue.

Our default builds are ODBC 3.0 by default, while some parts still maintain BC workarounds. The error S1091 witnesses that the driver is ODBC 2.x. Besides that, the technology seems to be not supported anymore - the support for the last FoxPro 9.0 product was discontinued over a year ago, and there are no new versions.

@eion, an option for you were to compile the required ext/odbc variant while setting --with-odbcver to like 0x0250 or other that is suitable for your app. The warning itself is useful as the actual reason adding it was about drivers that have inconsistent ODBC 3.x implementation.

Thanks.
 [2016-09-28 19:56 UTC] eion at robbmob dot com 
According to https://msdn.microsoft.com/en-us/library/ms716450(v=vs.85).aspx the call to SQLColAttribute() with SQL_DESC_OCTET_LENGTH will result in an error:

"If FieldIdentifier is one of the following: ... SQL_DESC_OCTET_LENGTH ...
the Driver Manager returns SQL_ERROR with SQLSTATE HY091 (Invalid descriptor field identifier). No further rules of this section apply."

I read this as expected behaviour that will happen with all ODBC 2.0 drivers when accessed using ODBC 3.0 functions and thus shouldn't be a warning in PHP if it's expected to work with ODBC 2.0 drivers.
 [2016-09-29 10:35 UTC] ab@php.net 
ext/odbc doesn't set the ODBC version at runtime, it is compiled in. When compiled with ODBC 3.0 support, it is compatible with ODBC 2.x drivers as much as the specification of 3.0 is.

Why we started to support 3.0 by default is the fact, that there are indeed no more apps running on ODBC 2.0. In the past few years, I haven't seen a bug about ODBC 2.0. Furthermore, ODBC 3.5 seems to be the usual case, whereby we don't rush into supporting it (in fact, there was no incompatibility reports). But, and that's the actual issue - some drivers in the world claim to support ODBC 3.x but don't implement it fully or are buggy in other ways.

Thus, the workarounds like the warning you see are only there because of such drivers. If you compile ext/odbc without ODBC 3.0 support, several parts will be excluded, thus you'll have an ext with pure ODBC 2.0 support. For the standard build, we have to handle the general case, however.

Thanks.
 [2016-10-04 02:59 UTC] eion at robbmob dot com 
The Foxpro ODBC driver isn't claiming to support ODBC 3.0, nor am I seeing any code in the PHP ODBC ext that is probing to see what version of ODBC the driver is, it just blindly assumes the SQL_DESC_OCTET_LENGTH attribute is available and tries to use it.

If the PHP ODBC ext is expecting to handle the general case of supporting ODBC 3, 3.5 and 2 drivers (as the ODBC 3 spec says there is fallback for) then the ext should be expecting and handling the SQL_DESC_OCTET_LENGTH attribute not existing (as per ODBC 3 backwards compat guidelines doc) for ODBC 2 drivers

I still don't see how this should be treated as a warning when it is expected behaviour when using ODBC 2 drivers.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 11:01:28 2024 UTC