Req #10549 [Opn->Fbk]: Performance problem with Openlink ODBC drivers
| From: | heiglandreas@php.net | Date: | Fri, 20 Jan 2017 17:04:43 +0000 |
| Subject: | Req #10549 [Opn->Fbk]: Performance problem with Openlink ODBC drivers | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-206766@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=10549&edit=1
ID: 10549
Updated by: heiglandreas@php.net
Reported by: a dot vdvelden at it dot correct dot nl
Summary: Performance problem with Openlink ODBC drivers
-Status: Open
+Status: Feedback
Type: Feature/Change Request
Package: ODBC related
Operating System: Suse Linux 6.2
PHP Version: 4.0.4pl1
Block user comment: N
Private report: N
New Comment:
Is this still relevant?
Previous Comments:
------------------------------------------------------------------------
[2001-05-11 14:58:42] kalowsky@php.net
This really isn't so much a bug, as a feature request. Marking it as so...
After speaking (briefly) with Stephan Schadt it is believed that moving from the current cursor
method (server-side) to something of a more mixed case is a GoodThing(TM).
We'll see if my free time allows this to make it in for 4.1 or not...
------------------------------------------------------------------------
[2001-05-10 14:04:09] ahill@php.net
this is a workaround for getting around the overhead required when server-side cursor libraries are
in use.
OpenLink 4.0 implements a mixed cursor library in the server-side components.
Server-side cursors should be used sparingly for this reason
-Stephen Schadt
------------------------------------------------------------------------
[2001-05-02 03:22:50] a dot vdvelden at it dot correct dot nl
I'm using the Openlink Data Access Driver Suite (Multi Tier Edition) Version 4.0, Connecting to
a Progress 8.3B Database running on an AIX Unix Box.
------------------------------------------------------------------------
[2001-05-01 16:59:38] kalowsky@php.net
before i commit such a patch, what version of OpenLink are you using?
------------------------------------------------------------------------
[2001-04-29 06:35:11] a dot vdvelden at it dot correct dot nl
Hello,
I've experienced a compilation error and some huge performance problems setting up an ODBC
connection via Openlink ODBC drivers.
I've configured my Php:
./configure --with-openlink=/usr/src/openlink
When compiling Php, it complains about missing the iodbc.h udbcext.h header files which are not
included in the SDK software package of Openlink.
When I remove the two above include files from ./ext/odbc/php_odbc.h line 125 128 the compilation
works fine without errors or warnings, and am able to etablish a connection to my Openlink drivers.
When I query my DB from out of Php via Openlink, a simple query takes huges amounts of time, while
the same query is very fast using the included odbctest utility from the Openlink SDK package.
I've run a query via Php and the odbctest utility and compared the two debug files and saw that
Php uses the ExtendedSQLFetch C- function. The odbctest utility uses an 'normal' SQLFetch
function.
So I have changed my ./ext/odbc/php_odbc.h file line 124 from:
#elif defined(HAVE_OPENLINK) /* OpenLink ODBC drivers */
#define ODBC_TYPE "Openlink"
#include <iodbc.h>
#include <isql.h>
#include <isqlext.h>
#include <udbcext.h>
#define HAVE_SQL_EXTENDED_FETCH 1
#define SQLSMALLINT SWORD
#define SQLUSMALLINT UWORD
to:
#elif defined(HAVE_OPENLINK) /* OpenLink ODBC drivers */
#define ODBC_TYPE "Openlink"
// #include <iodbc.h>
#include <isql.h>
#include <isqlext.h>
// #include <udbcext.h>
// #define HAVE_SQL_EXTENDED_FETCH 1
#undef HAVE_SQL_EXTENDED_FETCH
#define SQLSMALLINT SWORD
#define SQLUSMALLINT UWORD
With this small change I was able to compile my Php succesfully and query my Database via the
Openlink Package very fast!
Regards,
Anne van der Velden
Correct Express
The Netherlands
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=10549&edit=1