HI,
As maintainer of the iODBC driver manager project i have some fixed and
enhancements for the php odbc layer that i would like to submit for
review and inclusion into the code base.
The fixes that i made so far are:
a. Updating ext/odbc code to use ODBC 3.x datatypes so PHP can be used
with the ODBC64 specification on Windows 64bit, Mac OS X 10.5 and
Unix 64bit. These patches have been tested on these platforms and
should be compatible with any driver manager that conforms to the
ODBC 3.52 specification.
b. Fixed some iODBC and Openlink SDK related defines that where
out-of-date.
c. Added an extra setting to control the cursor model used by the php
odbc layer, which is a speedup for any application that does not need
a full dynamic cursor.
Please let me know what the appropriate way of sending these patches to
the relevant project members, or whether i should post them on this
mailing list.
Patrick
Hi Patrick,
As maintainer of the iODBC driver manager project i have some fixed and
enhancements for the php odbc layer that i would like to submit for
review and inclusion into the code base.
[...]
Please let me know what the appropriate way of sending these patches to
the relevant project members, or whether i should post them on this
mailing list.
You can either report it as a bug at bugs.php.net and provide a patch or
send the patch(es) as .txt file (the list will drop attachments of other
types) here.
In general: The ODBC extension seems to be quite unmaintained, the
registered maintainer did his last commit in 2004 if I didn't miss a
thing in the log. So, we're happy with any help in that area :-)
johannes
Hi Johannes,
As maintainer of the iODBC driver manager project i have some fixed and
enhancements for the php odbc layer that i would like to submit for
review and inclusion into the code base.[...]
Please let me know what the appropriate way of sending these patches to
the relevant project members, or whether i should post them on this
mailing list.You can either report it as a bug at bugs.php.net and provide a patch or
send the patch(es) as .txt file (the list will drop attachments of other
types) here.In general: The ODBC extension seems to be quite unmaintained, the
registered maintainer did his last commit in 2004 if I didn't miss a
thing in the log. So, we're happy with any help in that area :-)
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.
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.
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.
Patrick
Hi Patrick,
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? -
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? -
I hope these stuff won't break with other odbc flavors :-)
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.
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.
johannes
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