Hi Johannes,
I have attached 3 diffs as txt files. Each of the files start with a
short explanation of what the patch is supposed to do, so it is
easier
for anyone else to see what i did.
Tanks, I don't see a problem with these patches, while I don't really
know ODBC. But three comments:
- In general we try to avoid adding new ini settings, in general
they just make life harder, can't these made connection or query
flags?
Not easily with the current code i think. I did not want to add
another API function as this causes much more debate and
compatibility issues.
The current PHP code hardcodes a dynamic cursor for drivers that can
handle this. If not then normally the cursor downgrades to a static
cursor which happens with most of the open source drivers. But some
of the more advanced drivers are penalised by this behaviour as a
dynamic cursor is a lot slower than a static cursor. Most
applications do not need a full dynamic cursor to begin with as they
go over the record set only once. So this patch just levels the
playing field while still making sure that very advanced apps can use
a dynamic cursor if they choose so.
- The update for "current versions of iODBC": How new is this new
version? (Or other way round: how likely will a system break?)
Can old versions be detected and rejected from config.m4?
The current php code does not enable functionality like
SQLDriverConnect when using the iODBC driver manager. This function
has been part of the iODBC driver manager since its first publication
more than 9 years ago, and creates a nasty incompatibility
between various driver managers. Same goes for the use of
SQLExtendedFetch.
The result of this is that PHP applications that are written using
the php odbc_connect code work differently when PHP is compiled on
Windows or on Unix using iODBC whereas the whole point of the ODBC
API itself is to be a cross platform solution for data access.
- I hope these stuff won't break with other odbc flavors :-)
Not that i am aware of, as all ODBC driver managers currently
implement these types and features and have done so for at least 3 to
4 years.
If there are libraries that use an ODBC like api but do not have the
SQLLEN type etc, they cannot be used on 64bit Windows and 64bit Unix
to begin with, but for 32bit we can just add something like:
#ifndef SQLLEN
#define SQLLEN long
#endif
towards the end of php_odbc_includes.h to make them work.
All three diffs have been made against the PHP_5_2 branch of your CVS
tree and should be applied within the ext/odbc directory. Since i cut
them in pieces for easy reading, you can expect some warnings about
lines, but i checked and all three patches combine fine.
PHP_5_2 is the stable branch, new features should go to HEAD and
PHP_5_3, while I don't expect big problems with merging these.
I am also in contact with Dan Kalowsky the current maintainer of the
ext/odbc code and
i leave it up to him to recommend which version can be patches.
Of course i would like to see these patches be adopted as soon as
possible into the mainstream.
If there is any problem, please let me know as i am keen to get
this to
work properly.
Additionally if there is a list of TODO items for this module, i
will be
happy to see if i or my team can be of assistance.
There's no specific todo (I know off) but you might take a look at the
bug reports, see
http://bugs.php.net/search.php?
boolean=1&limit=20&cmd=display&status=Open&bug_type%5B%5D=ODBC
+related for a start.
I will certainly have a look at the list and see what i can do.
Patrick
---
Patrick van Kleef
Maintainer iODBC
OpenLink Software
Web: <http://www.iodbc.org>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
