ID: 33184 User updated by: brad_allgood at csgsystems dot com Reported By: brad_allgood at csgsystems dot com -Status: Feedback +Status: Open Bug Type: ODBC related Operating System: Windows XP PHP Version: 5.0.4 New Comment:
I can not get the PECL extension to work. When I load it via the php.ini setting: "extension=php_ibm_db2.dll" I get the following errors when I try invoke the script via the command line php.exe - Entry Point Not Found The procedure entry point [EMAIL PROTECTED] could not be located in the dynamic link library DB2CLI.dll Warning: PHP Startup: Unable to load dynamic library 'c:\php\ext\php_ibm_db2.dll' - The specified procedure could not be found. On the machine I am running the script from (client) the dblevel command outputs: DB21085I Instance "DB2" uses DB2 code release "SQL07010" with level identifier "02020105" and informational tokens "DB2 v7.1.0.1", "n000727" and "WR21198". On the machine that has the database I am querying the db2level command outputs: DB21085I Instance "db2inst1" uses DB2 code release "SQL07020" with level identifier "03010105" and informational tokens "DB2 v7.1.0.40", "s010415" and "U475375". So given all this am I to understand that the PECL db2 component is not a viable option for me unless I upgrade to DB2 V8.1? I am assuming that is the issue with the ibm_db2_php.dll starting up due to dependencies in db2_cli.dll ... unless I've got something goofy in my pathing to get to the db2_cli.dll. The "echo %PATH%" command I am running the php command from is echo %PATH% C:\Perl\bin\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Microsoft SQL Server\80\Tools\BINN;C:\Program Files\ActiveState Komodo 3.1 \;c:\php;C:\Program Files\SQLLIB\BIN;C:\Program Files\SQLLIB\HELP;c:\php\ext;c:\ php\includes;c:\php\includes\jpgraph;c:\php\includes\jpgraph\src The db2cli.dll is located in c:\Program Files\SQLLIB\BIN which is in my path. Back to the orignal submission: It looked like in 16221 someone had a track on this in the 4.X branch of code. Did this not pan out or has that cause been ruled out as part of the original odbc related bug submission I created? Previous Comments: ------------------------------------------------------------------------ [2005-05-31 00:01:09] [EMAIL PROTECTED] Brad: 1) Can you reproduce the error with the PECL ibm_db2 extension? You can grab the php_ibm_db2.dll from http://snaps.php.net/, change odbc_* to db2_* in your function calls (with the exception of odbc_connect() -- I think you'll need to add USER=user;PASSWORD=password; to your connection string and pass nulls for the second and third parameter), and everything _should_ work. Note that this requires a minimum of DB2 V8.2. 2) What levels of DB2 are you running on your Windows box and AIX server? ------------------------------------------------------------------------ [2005-05-30 20:24:07] brad_allgood at csgsystems dot com Okay ... I'm inlcuding a script written and tested on my machine to reproduce the error: //################## Script Start ######################## <?php $b_date = '05/25/2005'; $b_time = '09:00:00'; $m_mach_sn = "075-21752"; $connect_string = "Driver={IBM DB2 ODBC Driver};HOSTNAME=host.domain.com;DATABASE=TEST;PROTOCOL=TCPIP;PORT=50000;"; $conn = odbc_connect($connect_string, 'user', 'password'); $counter=0; while ($counter <5000) { $vpcfg_qry = "select distinct m_mach_sn, m_cluster_n, m_card_num, m_lss_la, m_array_id, m_loop_id, m_grp_num, m_disk_num from db2inst1.vpcfg where m_mach_sn = '$m_mach_sn' order by m_mach_sn, m_card_num, m_cluster_n, m_loop_id, m_grp_num "; // Get Result $vpcfg_result = odbc_exec($conn,$vpcfg_qry); //print "m_mach_sn|m_cluster_n|m_card_num|m_lss_la|m_array_id|m_loop_id|m_grp_num|m_disk_num|m_dbl_wide<br>\n"; // Get Data From Result $vpcfg_row_count = 0; while ($vpcfg_row[] = odbc_fetch_array($vpcfg_result)) { $m_mach_sn = $vpcfg_row[$vpcfg_row_count]["M_MACH_SN"]; $m_cluster_n = $vpcfg_row[$vpcfg_row_count]["M_CLUSTER_N"]; $m_card_num = $vpcfg_row[$vpcfg_row_count]["M_CARD_NUM"]; $m_lss_la = $vpcfg_row[$vpcfg_row_count]["M_LSS_LA"]; $m_array_id = $vpcfg_row[$vpcfg_row_count]["M_ARRAY_ID"]; $m_loop_id = $vpcfg_row[$vpcfg_row_count]["M_LOOP_ID"]; $m_grp_num = $vpcfg_row[$vpcfg_row_count]["M_GRP_NUM"]; $m_disk_num = $vpcfg_row[$vpcfg_row_count]["M_DISK_NUM"]; } print "Counter = $counter\n"; $counter = $counter + 1; } odbc_close($conn) ?> //################## Script End ######################## ------------------------------------------------------------------------ [2005-05-30 19:48:52] denials at gmail dot com What is the expected result of the test script? In reading the script (and ignoring the extra close brace in line 4 that would cause a syntax error), I would expect the loop to start issuing errors after the first iteration, as odbc_close_all() should close the connection if no transactions are in progress. Given the subject of the bug, I'm assuming you're seeing an SQL0954C instead, which would indicate that odbc_close_all() is not, in fact, doing its job. However, I have been unable to reproduce this result on Windows XP, Apache 2.0.52, PHP 5.0.4, DB2 Version 8.2 connecting locally or to a remote DB2 server on a Linux box. The APPLHEAPSZ setting on the Windows server is the default of 256 4K pages. ------------------------------------------------------------------------ [2005-05-30 16:08:11] brad_allgood at csgsystems dot com I do not think this is a db related issue as I can run the same query from the command line on the server running the db and it works fine. I cut and pasted the original bug report as I thought this may have been overlooked in the php5 development cycle. I am running the php script on a windows xp machine using odbc calls against a remote db2 machine using an explict connection string call. $connect_string = "Driver={IBM DB2 ODBC Driver};HOSTNAME=host.domain.com;DATABASE=SOMEDB;PROTOCOL=TCPIP;PORT=X0000;"; ------------------------------------------------------------------------ [2005-05-30 15:29:25] [EMAIL PROTECTED] SQL0954C Not enough storage is available in the application heap to process the statement. Explanation: All available memory for the application has been used. The statement cannot be processed. User Response: Terminate the application on receipt of this message. Increase the database configuration parameter (applheapsz) to allow a larger application heap. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/33184 -- Edit this bug report at http://bugs.php.net/?id=33184&edit=1
