« kansas bound simon | Main | customer service pt2 »
August 28, 2003
BLOB support for PHP
For those who haven't been paying attention today to the PHP mailing lists, I broke the build, or at least those that follow and use the ODBC extension by default (*cough* Windows *cough*). Why did I break the build?
The patch provided by Clara Liu was supposed to add/simplify BLOB support within PHP's current architecture. The catch (there's always a catch) is that there is no default data type for a BLOB in ODBC. As such, Clara decided to emulate BLOB behavior via a SQL_LONGVARBINARY type, which should work just fine. The build problem showed it's ugly face when the patch she sent expects a #define for a type of SQL_BLOB that just does not exist on the 3 major driver managers I support (iODBC, unixODBC, and Windows).
There are two options to fixing this that I see, but I do need people to test them.
The first patch simply adds in a "#define SQL_BLOB SQL_LONGVARCHAR" to the system and hopes all is right.
The second patch removes the use of the word SQL_BLOB as a case type, and hopes that REGISTER_LONG_CONSTANT will properly convert a SQL_BLOB over to a SQL_LONGVARBINARY.
Any testing of these patches would be appreciated since I cannot test them currently. As always comments and feedback are looked upon fondly. Email, comments, and trackbacks all work very well.
So why did I commit this basically untested patch? To get it tested first off. I had a handful of people claiming it worked great for them, but they were all limited to the same DB types and this patch needed further testing. Many of those wanting to test were Windows users without compilers, and as such the only way to enable their testing was to give them a snapshot. Seeing as I have now Windows machine around me, this was my best option. I don't have much hope that these current patches will even be tested, but I could be proven wrong.
On another note, if none of this works I'll abandon the attempts to make this work.
Posted by Dan at August 28, 2003 03:16 PM
Comments
Hi! I applied your second patch to the latest php-cvs version (from yesterday) to solve the bug from http://bugs.php.net/bug.php?id=25118
Now I tried it both with unixODBC and with the --with-ibm-db2 option - none of those worked. But I saw that a fixpack 3 for DB/2 was released now (I use fixpack 2), so I'm going to try this on sunday or monday.
I've been trying to solve this for more than a month now, so soon I'll give up and port my application to postgresql ;)
Posted by: Jan Schreiber at August 30, 2003 02:32 AM
Some interesting problem, we hope you can help us
We have a test table (c1 int not null,c2 char(2),c3 char(2)) in db2 (v 7.2 fix 7)
we have created a unique index on (c1) includes (c2,c3)
we have a test data
1,'A','B'
2,'A',null,
3,null,'B'
4,null,null
and the php script as follows
";
$odbc_res=odbc_exec($Conn,$sel);
echo $odbc_res . "";
while(odbc_fetch_row($odbc_res))
{
echo "Record : ";
echo odbc_result($odbc_res,1);
echo "-";
echo odbc_result($odbc_res,2);
echo "-End Record";
}
?>
We are getting strange result.
We located that this problem arises because of defination of unique key and c2 or c3 are containing null values.
If you find a solution to this kindly reply on jay@nicwr.mah.nic.in
Posted by: Sanjay Londhe at November 1, 2003 03:35 AM