ZF-4894: Zend_Db_Adapter_Db2 does not work with iSeries (AS/400)
Description
The reason is the sql statement in the describeTable() method. If you change it to our version, it works. We have created a modified version of Zend_Db_Adapter_Db2 called Zend_Db_Adapter_Db2iseries, that overloads this method, but I think, that some kind of option in Zend_Db_Adapter_Db2 will be better. We are using ZF 1.5.3 now, so it is possible, that it will be necessary to adapt the code for 1.7.x
It seems, that this will not work for z/OS version of DB2, only for AS400
This is our sql code:
$sql = "SELECT DISTINCT c.table_schema, c.table_name, c.column_name, c.ordinal_position,
c.data_type, c.column_default, c.is_nullable, c.length, c.numeric_scale,
c.is_identity, tc.type AS tabconsttype, k.colseq
FROM qsys2.syscolumns c
LEFT JOIN (qsys2.syskeys k JOIN qsys2.syscst tc
ON (k.index_schema = tc.table_schema
AND k.index_name = tc.table_name
AND tc.type = 'PRIMARY KEY'))
ON (c.table_schema = k.index_schema
AND c.table_name = k.index_name
AND c.column_name = k.column_name)
WHERE "
. $this->quoteInto('UPPER(c.table_name) = UPPER(?)', $tableName);
if ($schemaName) {
$sql .= $this->quoteInto(' AND UPPER(c.table_schema) = UPPER(?)', $schemaName);
}
$sql .= " ORDER BY c.ordinal_position";
Comments
Posted by Wil Sinclair (wil) on 2008-12-04T13:57:06.000+0000
Can't you close this with fix for 1.7.0, Ralph?
Posted by old of Satoru Yoshida (yoshida@zend.co.jp) on 2008-12-08T01:44:25.000+0000
Solved in SVN r13093
Posted by Ralph Schindler (ralph) on 2008-12-15T09:25:47.000+0000
Satoru, the changes you applied broke unit tests on i5 for OS400 on my v5r4. I am gonna update, then can you test on your i5?
Will keep you posted.
-ralph
Posted by old of Satoru Yoshida (yoshida@zend.co.jp) on 2008-12-15T17:43:23.000+0000
Hi, Ralph. Ok , I will test on my i5 after your commits.
Posted by old of Satoru Yoshida (yoshida@zend.co.jp) on 2009-04-03T19:39:29.000+0000
I schedule to work on this in May/2009.
Posted by old of Satoru Yoshida (yoshida@zend.co.jp) on 2009-05-08T01:15:06.000+0000
I confirm this issue would not be shown in following test code. This seems to be resolved in 1.7.3 .