[PHP-DEV] Bug #14602 Updated: Compilation of PHP 4.1.0 with libiodbc 3.0.5 support failed
ID: 14602 Updated by: ahill Reported By: [EMAIL PROTECTED] Old Status: Open Status: Analyzed Bug Type: ODBC related Operating System: FreeBSD 4.3, RedHat 7.1 PHP Version: 4.1.0 Old Assigned To: Assigned To: ahill New Comment: I was unable to reproduce, using Redhat 7.1, PHP 4.1.0 and libiobc 3.0.5 with the following configure: ./configure \ --with-iodbc=/dbs/openlink/v41/odbcsdk --with-apache=../apache_1.3.22 \ --enable-track-vars Previous Comments: [2001-12-19 07:55:38] [EMAIL PROTECTED] I am unable to compile PHP 4.1.0 with libiodbc 3.0.5 Here is what I did: $ ls libiodbc-3.0.5.tar.gz php-4.1.0.tar.gz $ tar xzf libiodbc-3.0.5.tar.gz $ cd libiodbc-3.0.5 $ ./configure --prefix=/home/kan/tmp --disable-shared --disable-gui . $ gmake . $ gmake install . $cd .. $ tar xzf php-4.1.0.tar.gz $ cd php-4.1.0 $ ./configure --with-apxs=/usr/local/apache/bin/apxs --with-iodbc=/home/kan/tmp --without-mysql --without-xml $ make . Making all in . /bin/sh /usr/home/kan/tmp/test/php-4.1.0/libtool --silent --mode=compile gcc -I. -I/usr/home/kan/tmp/test/php-4.1.0/ -I/usr/home/kan/tmp/test/php-4.1.0/main -I/usr/home/kan/tmp/test/php-4.1.0 -I/home/kan/tmp/include -I/usr/local/psa/apache/include -I/usr/home/kan/tmp/test/php-4.1.0/Zend -I/home/kan/tmp/include -DHARD_SERVER_LIMIT=2048 -DDEFAULT_PATH=/usr/local/psa/apache/bin:/bin:/usr/bin -DMOD_SSL=208105 -DMOD_PERL -DUSE_PERL_SSI -DEAPI -DEAPI_MM -DUSE_EXPAT -I/usr/home/kan/tmp/test/php-4.1.0/TSRM -g -O2 -prefer-pic -c stub.c /bin/sh /usr/home/kan/tmp/test/php-4.1.0/libtool --silent --mode=link gcc -I. -I/usr/home/kan/tmp/test/php-4.1.0/ -I/usr/home/kan/tmp/test/php-4.1.0/main -I/usr/home/kan/tmp/test/php-4.1.0 -I/home/kan/tmp/include -I/usr/local/psa/apache/include -I/usr/home/kan/tmp/test/php-4.1.0/Zend -I/home/kan/tmp/include -DHARD_SERVER_LIMIT=2048 -DDEFAULT_PATH=/usr/local/psa/apache/bin:/bin:/usr/bin -DMOD_SSL=208105 -DMOD_PERL -DUSE_PERL_SSI -DEAPI -DEAPI_MM -DUSE_EXPAT -I/usr/home/kan/tmp/test/php-4.1.0/TSRM -g -O2 -prefer-pic -o libphp4.la -rpath /usr/home/kan/tmp/test/php-4.1.0/libs -avoid-version -L/home/kan/tmp/lib -R /home/kan/tmp/lib stub.lo Zend/libZend.la sapi/apache/libsapi.la main/libmain.la regex/libregex.la ext/odbc/libodbc.la ext/pcre/libpcre.la ext/posix/libposix.la ext/session/libsession.la ext/standard/libstandard.la TSRM/libtsrm.la -L/home/kan/tmp/lib -liodbc -lpam -liodbc -lcrypt -lm -lcrypt Zend/.libs/libZend.al(catalog.o): In function `SQLGetTypeInfo': /usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c(.text+0xd0): multiple definition of `SQLGetTypeInfo' Zend/.libs/libZend.al(catalog.o)(.text+0xd0):/usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c: first defined here Zend/.libs/libZend.al(catalog.o): In function `SQLSpecialColumns': /usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c(.text+0x2b4): multiple definition of `SQLSpecialColumns' Zend/.libs/libZend.al(catalog.o)(.text+0x2b4):/usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c: first defined here Zend/.libs/libZend.al(catalog.o): In function `SQLStatistics': /usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c(.text+0x5dc): multiple definition of `SQLStatistics' Zend/.libs/libZend.al(catalog.o)(.text+0x5dc):/usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c: first defined here Zend/.libs/libZend.al(catalog.o): In function `SQLTables': /usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c(.text+0x8c4): multiple definition of `SQLTables' Zend/.libs/libZend.al(catalog.o)(.text+0x8c4):/usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c: first defined here . (many such strings) .. /home/kan/tmp/lib/libiodbc.a(odbc3.o): In function `SQLBindParam': /usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/odbc3.c(.text+0x4484): multiple definition of `SQLBindParam' Zend/.libs/libZend.al(odbc3.o)(.text+0x4484):/usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/odbc3.c: first defined here /home/kan/tmp/lib/libiodbc.a(odbc3.o): In function `SQLCloseCursor': /usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/odbc3.c(.text+0x44bc): multiple definition of `SQLCloseCursor' Zend/.libs/libZend.al(odbc3.o)(.text+0x44bc):/usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/odbc3.c: first defined here *** Error code 1 Stop in /usr/home/kan/tmp/test/php-4.1.0. *** Error code 1 Stop in /usr/home/kan/tmp/test/php-4.1.0. $ I am supposing that libZend.la library contains libiodbc.a library functions. And in the last compile command both libZend and libiodbc are presents. So conflict with multiply definition somewhere here. Thanks, defencer. Edit
[PHP-DEV] Bug #13154 Updated: ODBC query to Openingres 2.0 fail with scs_p_GetTblAttribs: DRV_DDTables failed
ID: 13154
Updated by: ahill
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: ODBC related
Operating System: Solaris 8
PHP Version: 4.0.6
Assigned To: ahill
New Comment:
We've not had any problems with your configuration - are you getting an error message?
Best regards,
Andrew Hill
Previous Comments:
[2001-12-07 12:25:32] [EMAIL PROTECTED]
Assigning this to Ahill as he knows the OpenLink software best.
[2001-09-05 14:57:19] [EMAIL PROTECTED]
No queries can be made with PHP 4 and Openlink ODBC to access OpenIngres.
Test program:
? echo Teste de ODBCP ;
$odbc = odbc_connect(Desenv , notes, notes, SQL_CUR_USE_IF_NEEDED );
echo ODBC_CONNECT return code: $odbc ;
$query = select matrica from srhtb002;
$queryprep = odbc_prepare ($odbc, $query); // This produces the error.
$result = odbc_execute($queryprep );
print ok. result = $result;
$nextrow = odbc_fetch_row($result, 1);
if (! $nextrow ) {
print Nco achou nada...br;
}
else {
print odbc_result($result , 1 );
print br;
print odbc_result($result , 2 );
}
?
The configure line is:
./configure --enable-track-vars --with-yp --with-apxs --with-oci8
--with-iodbc=/software/openlink/odbcsdk
Edit this bug report at http://bugs.php.net/?id=13154edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14072 Updated: PHP Causes OpenLink Request Broker (odbc_mv.exe) to Segfault upon odbc_do, etc.
ID: 14072 Updated by: ahill Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Operating System: FreeBSD 4.3 PHP Version: 4.0.6 New Comment: 1. only compile --with-iodbc. Please try this an retest. 2. the reqest broker is oplrqb. the component you report as segfaulting, odbc_mv.exe is the odbc agent - which is it, and how are you determining the windows binary is segfaulting? Either way, please recompile --with-iodbc and test. Best regards, Andrew Hill OpenLink Software Previous Comments: [2001-11-15 14:05:58] [EMAIL PROTECTED] (Whoops, I forgot to mention that this is a standard MS Access DSN) Client Platform: Apache 1.3.20/PHP 4.0.6/OpenLink Data Access Drivers (Current as of yesterday), PHP Compiled --with-iodbc --with-openlink Server Platform: WinNT 4.5 SBS, OpenLink Request Broker (Current as of yesterday). When attempting to execute ANY query, ie: select * from table via any method (odbc_do, odbc_exec, odbc_prepare/odbc_execute, etc..) PHP causes a segfault in the Request Broker on the NT machine. This appears to be PHP specific. ./odbctest works fine, and I can establish a connection to my odbc datasource and get any data directly. I have submitted a bug report to OpenLink software as well, but it appears to be PHP specific. Client machine remains running. [2001-11-15 14:03:19] [EMAIL PROTECTED] Client Platform: Apache 1.3.20/PHP 4.0.6/OpenLink Data Access Drivers (Current as of yesterday), PHP Compiled --with-iodbc --with-openlink Server Platform: WinNT 4.5 SBS, OpenLink Request Broker (Current as of yesterday). When attempting to execute ANY query, ie: select * from table via any method (odbc_do, odbc_exec, odbc_prepare/odbc_execute, etc..) PHP causes a segfault in the Request Broker on the NT machine. This appears to be PHP specific. ./odbctest works fine, and I can establish a connection to my odbc datasource and get any data directly. I have submitted a bug report to OpenLink software as well, but it appears to be PHP specific. Client machine remains running. Edit this bug report at http://bugs.php.net/?id=14072edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11595 Updated: Error in the migration PHP3 to PHP4 with OpenLink-ODBC drive
ID: 11595 Updated by: ahill Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Closed Bug Type: ODBC related Operating System: Solaris 2.7 PHP Version: 4.0.4pl1 Assigned To: ahill New Comment: unable to duplicate, no feedback Previous Comments: [2001-07-30 12:08:34] [EMAIL PROTECTED] Hi, Please try with 4.0.6 or submit an ODBC trace; I am unable to reproduce. Best regards, Andrew [2001-07-09 16:08:07] [EMAIL PROTECTED] Nico, Can you please generate a trace? I expect we will see a problem in the SQLPrepare where it's dropping your subquery. To enable tracing, add or uncomment the following line in the $ODBCINI file: DebugFile=/tmp/opl_debug.out and then please paste the resultant trace in. Best regards, Andrew Hill OpenLink Software [2001-06-26 17:59:09] [EMAIL PROTECTED] assigning to ahill as he knows openlink best :) [2001-06-21 11:13:00] [EMAIL PROTECTED] Sorry, message error: Warning: SQL error: [OpenLink][ODBC][Driver]General error, SQL state S1000 in SQLPrepare in /psitio/multihomed/www.elsitio.com/pub/cgi-bin/gl/av/player/test.php3 on line 19 The most strange is that I reduce the query string SELECT P.* FROM REAL_CAT_PADRE P WHERE IDIOMA = 'C' AND P.ID_PADRE IN ( SELECT ID_HIJO FROM REAL_CAT_HIJO ) to SELECT P.* FROM REAL_CAT_PADRE P WHERE IDIOMA = 'C' it works fine IN PHP4... I don't know is very strange. Nico. [2001-06-21 11:10:52] [EMAIL PROTECTED] marking as feedback until user responds... 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/?id=11595 Edit this bug report at http://bugs.php.net/?id=11595edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13783 Updated: odbc_fetch_into different issue
ID: 13783
Updated by: ahill
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: ODBC related
Operating System: SCO Openserver 5.0.5 RH Lnux 7
PHP Version: 4.0.6
New Comment:
The current SDK version is 3.0.5 and isql.h is included in it. Please get the SDK from
either www.openlinksw.com or www.iodbc.org and recompile without commenting out the
references.
Best regards,
Andrew Hill
OpenLink Software
Previous Comments:
[2001-10-22 20:59:00] [EMAIL PROTECTED]
No errors at all, just returns an empty recordset.
One probably important note. When I compiled PHP 4.0.6 I had to remove the reference
to isql.h? in the php_odbc source program as it wasn't in the Openlink SDK for
Openlink 4.1.
Everything seems to work except the selected record stuff which hasn't ever worked for
me using PHP 4 against Openlink.
I think I had it working under PHP 3.0.15 against Openlink 3.2, but we have moved on
since then.
[2001-10-22 20:56:36] [EMAIL PROTECTED]
Using odbc_fetch_into($id, $number, $result_array);
SQLAllocHandle ( ... )
SQL_SUCCESS
SQLSetStmtAttr ( ... )
SQL_SUCCESS
SQLAllocHandle ( ... )
SQL_SUCCESS
SQLDriverConnect ( ... )
SQL_SUCCESS
SQLGetInfo ( ... )
SQL_SUCCESS
SQLGetInfo ( ... )
SQL_SUCCESS
SQLAllocHandle ( ... )
SQL_SUCCESS
SQLGetStmtAttr ( ... )
SQL_SUCCESS
SQLGetStmtAttr ( ... )
SQL_SUCCESS
SQLGetStmtAttr ( ... )
SQL_SUCCESS
SQLGetStmtAttr ( ... )
SQL_SUCCESS
SQLGetInfo ( ... )
SQL_SUCCESS
SQLSetStmtAttr ( ... )
SQL_SUCCESS
SQLExecDirect ( ... )
SQL_SUCCESS
SQLNumResultCols ( ... )
SQL_SUCCESS
SQLNumResultCols ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLBindCol ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLBindCol ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLBindCol ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLBindCol ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLBindCol ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLBindCol ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLBindCol ( ... )
SQL_SUCCESS
SQLExtendedFetch ( ... )
SQL_SUCCESS
SQLExtendedFetch ( ... )
SQL_ERROR
SQLFreeHandle ( ... )
SQL_SUCCESS
SQLDisconnect ( ... )
SQL_SUCCESS
SQLFreeHandle ( ... )
SQL_SUCCESS
SQLFreeHandle ( ... )
SQL_SUCCESS
[2001-10-22 10:31:58] [EMAIL PROTECTED]
Status - Feedback
[2001-10-22 09:38:15] [EMAIL PROTECTED]
Are you getting error messages?
Also, please generate an odbc trace; uncomment the DebugFile section in odbc.ini.
Best regards,
Andrew Hill
OpenLink Software
[2001-10-21 20:59:21] [EMAIL PROTECTED]
Platforms:
Using PHP 4.0.6/Openlink 4.1/Progress 8.3D.
Other:
I've tried PHP 4.0.4/4.0.5/4.0.6, Openlink 3.2,4.0,4.1, Progress 8.3C,8.3D,9.1C,
shared memory and TCP/IP based connections.
Problem:
Doesn't seem to matter what I do, I am completely unable to select specific rows using
ODBC.
I think the code below is correct, it's snipped from scripts.
?
$dsn=DSN=$database;UID=$user;PWD=$password;
// I've tried all these without a difference.
$cursor=SQL_CUR_USE_ODBC;
//$cursor=SQL_CUR_IF_NEEDED;
//$cursor=SQL_CUR_USE_DRIVER;
//$cursor=SQL_CUR_DEFAULT;
$sql=SELECT * FROM user_table;
$text=;
function db_fetch_into($id, $number) {
global $text;
$text = TDROW: $number/TD;
//Never Returns Anything
//odbc_fetch_into($id, $number, $result_array);
//Always Works
odbc_fetch_into($id, $result_array);
//Always Works
//odbc_fetch_into($id, 0, $result_array);
return $result_array;
}
if ($conn=odbc_connect($dsn,,,$cursor)){
echo TABLE border='1';
//while ((odbc_fetch_into($results,$pos,$row)) ($count$limit)) {
$pos=0;
while ((list($var1,$var2) = db_fetch_into($result, $pos)) ($pos10)) {
echo TR$textTD$var1/TDTD$var2/TD/TR;
$pos ++;
}
echo /TABLE;
odbc_free_result($result);
odbc_close($conn);
} else {
// No connection
[PHP-DEV] Bug #13783 Updated: odbc_fetch_into different issue
ID: 13783
Updated by: ahill
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Analyzed
Bug Type: ODBC related
Operating System: SCO Openserver 5.0.5 RH Lnux 7
PHP Version: 4.0.6
Old Assigned To:
Assigned To: ahill
Previous Comments:
[2001-10-22 20:59:00] [EMAIL PROTECTED]
No errors at all, just returns an empty recordset.
One probably important note. When I compiled PHP 4.0.6 I had to remove the reference
to isql.h? in the php_odbc source program as it wasn't in the Openlink SDK for
Openlink 4.1.
Everything seems to work except the selected record stuff which hasn't ever worked for
me using PHP 4 against Openlink.
I think I had it working under PHP 3.0.15 against Openlink 3.2, but we have moved on
since then.
[2001-10-22 20:56:36] [EMAIL PROTECTED]
Using odbc_fetch_into($id, $number, $result_array);
SQLAllocHandle ( ... )
SQL_SUCCESS
SQLSetStmtAttr ( ... )
SQL_SUCCESS
SQLAllocHandle ( ... )
SQL_SUCCESS
SQLDriverConnect ( ... )
SQL_SUCCESS
SQLGetInfo ( ... )
SQL_SUCCESS
SQLGetInfo ( ... )
SQL_SUCCESS
SQLAllocHandle ( ... )
SQL_SUCCESS
SQLGetStmtAttr ( ... )
SQL_SUCCESS
SQLGetStmtAttr ( ... )
SQL_SUCCESS
SQLGetStmtAttr ( ... )
SQL_SUCCESS
SQLGetStmtAttr ( ... )
SQL_SUCCESS
SQLGetInfo ( ... )
SQL_SUCCESS
SQLSetStmtAttr ( ... )
SQL_SUCCESS
SQLExecDirect ( ... )
SQL_SUCCESS
SQLNumResultCols ( ... )
SQL_SUCCESS
SQLNumResultCols ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLBindCol ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLBindCol ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLBindCol ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLBindCol ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLBindCol ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLBindCol ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLColAttribute ( ... )
SQL_SUCCESS
SQLBindCol ( ... )
SQL_SUCCESS
SQLExtendedFetch ( ... )
SQL_SUCCESS
SQLExtendedFetch ( ... )
SQL_ERROR
SQLFreeHandle ( ... )
SQL_SUCCESS
SQLDisconnect ( ... )
SQL_SUCCESS
SQLFreeHandle ( ... )
SQL_SUCCESS
SQLFreeHandle ( ... )
SQL_SUCCESS
[2001-10-22 10:31:58] [EMAIL PROTECTED]
Status - Feedback
[2001-10-22 09:38:15] [EMAIL PROTECTED]
Are you getting error messages?
Also, please generate an odbc trace; uncomment the DebugFile section in odbc.ini.
Best regards,
Andrew Hill
OpenLink Software
[2001-10-21 20:59:21] [EMAIL PROTECTED]
Platforms:
Using PHP 4.0.6/Openlink 4.1/Progress 8.3D.
Other:
I've tried PHP 4.0.4/4.0.5/4.0.6, Openlink 3.2,4.0,4.1, Progress 8.3C,8.3D,9.1C,
shared memory and TCP/IP based connections.
Problem:
Doesn't seem to matter what I do, I am completely unable to select specific rows using
ODBC.
I think the code below is correct, it's snipped from scripts.
?
$dsn=DSN=$database;UID=$user;PWD=$password;
// I've tried all these without a difference.
$cursor=SQL_CUR_USE_ODBC;
//$cursor=SQL_CUR_IF_NEEDED;
//$cursor=SQL_CUR_USE_DRIVER;
//$cursor=SQL_CUR_DEFAULT;
$sql=SELECT * FROM user_table;
$text=;
function db_fetch_into($id, $number) {
global $text;
$text = TDROW: $number/TD;
//Never Returns Anything
//odbc_fetch_into($id, $number, $result_array);
//Always Works
odbc_fetch_into($id, $result_array);
//Always Works
//odbc_fetch_into($id, 0, $result_array);
return $result_array;
}
if ($conn=odbc_connect($dsn,,,$cursor)){
echo TABLE border='1';
//while ((odbc_fetch_into($results,$pos,$row)) ($count$limit)) {
$pos=0;
while ((list($var1,$var2) = db_fetch_into($result, $pos)) ($pos10)) {
echo TR$textTD$var1/TDTD$var2/TD/TR;
$pos ++;
}
echo /TABLE;
odbc_free_result($result);
odbc_close($conn);
} else {
// No connection .
}
?
Edit this bug report at http://bugs.php.net/?id=13783edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail
[PHP-DEV] Bug #13501 Updated: --with-iodbc, --with-ibm-db2 doesn't work together when using ./configure
ID: 13501
Updated by: ahill
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: *Configuration Issues
Operating System: AIX 4.3.3
PHP Version: 4.0.6
New Comment:
It's your LD_LIBRARY_PATH.
Modify it to indclude the libpath stuff after the db2 ld_library_path stuff.
Best regards,
Andrew Hill
OpenLink Software
Previous Comments:
[2001-10-22 04:32:39] [EMAIL PROTECTED]
You can't use iodbc and ibm-db2 (or any other uodbc combination) together.
Just use iodbc and db2 as driver for iodbc.
[2001-10-20 19:51:03] [EMAIL PROTECTED]
Please include the part of config.log which might
show why iodbc check fails.
--Jani
[2001-10-01 16:27:26] [EMAIL PROTECTED]
When proceeding to use the './configure' command and include the 2 options,
'--with-iodbc' and '--with-ibm-db2'. The configure only configure the IBM DB2 and
does not do anything with the iODBC. So, when compiling the PHP, it only include the
IBM DB2 and that's it. It doesn't include the iODBC.
Here's the configure command I use
--clip begin--
./configure
--with-apache=../apache_1.3.20
--with-ibm-db2=/usr/lpp/db2_06_01
--with-iodbc=/usr/local/odbcsdk
--with-openssl=../openssl-0.9.6b
--with-mcrypt=../libmcrypt-2.4.15
--without-mysql
--with-config-file-path=/etc
--enable-track-vars
--clip end--
Here's the copy of hte environment variable as result of the export command by
typing in export and pressing enter.
--clip begin--
declare -x AUTHSTATE=compat
declare -x CFLAGS=-O2 -I/usr/local/ssl/include -I/usr/local/odbcsdk/include
declare -x CGI_DIRECTORY=/var/docsearch/cgi-bin
declare -x DB2DIR=/usr/lpp/db2_06_01
declare -x DB2INSTANCE=db2inst1
declare -x DOCUMENT_DIRECTORY=/usr/docsearch/html
declare -x DOCUMENT_SERVER_MACHINE_NAME=localhost
declare -x DOCUMENT_SERVER_PORT=49213
declare -x HOME=/
declare -x HOSTNAME=test
declare -x HOSTTYPE=powerpc
declare -x IMQCONFIGCL=/etc/IMNSearch/dbcshelp
declare -x IMQCONFIGSRV=/etc/IMNSearch
declare -x INSTHOME=/home/db2inst1/sqllib/lib
declare -x LANG=en_US
declare -x LC__FASTMSG=true
declare -x LDFLAGS=-L/usr/local/ssl/lib -L/usr/local/odbcsdk/lib
declare -x LD_LIBRARY_PATH=/home/db2inst1/sqllib/lib:/usr/local/lib
declare -x LIBPATH=/usr/local/odbcsdk/lib
declare -x LOCPATH=/usr/lib/nls/loc
declare -x LOGIN=root
declare -rx LOGNAME=root
declare -x MACHTYPE=powerpc-ibm-aix4.3.2.0
declare -x MAIL=/usr/spool/mail/root
declare -x MAILMSG=[YOU HAVE NEW MAIL]
declare -x MANPATH=:/usr/local/man:/usr/dt/man:usr/share/man
declare -x NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat
declare -x ODBCINI=/usr/local/odbcsdk/doc/odbc.ini
declare -x ODMDIR=/etc/objrepos
declare -x OLDPWD=/usr/local/src
declare -x OSTYPE=aix4.3.2.0
declare -x
PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/local/bin:/usr/local/apache/bin
declare -x
PS1=\\[\\e[00;33m\\]-=\\[\\e[00;33m\\][\\[\\e[01;33m\\]\\u@\\h\\[\\e[00;33m\\]]\\[\\e[00m\\]\\n\\[\\e[00;31m\\]-=\\[\\e[00;31m\\][\\[\\e[01;31m\\]\`pwd\`\\[\\e[00;31m\\]]\\[\\e[01;31m\\]==\\[\\e[00m\\]
declare -x PWD=/usr/local/src/php-4.0.6
declare -x SHELL=/usr/local/bin/bash
declare -x SHLVL=1
declare -x SSL_APP_DIR=/usr/local/ssl/bin
declare -x SSL_BASE=/usr/local/ssl
declare -x SSL_LIB_DIR=/usr/local/ssl/lib
declare -x TERM=vt220
declare -x TZ=CST6CDT
declare -x USER=root
--clip end--
Here's the result that are being displayed as result of using the configure command.
--clip begin--
creating cache ./config.cache
checking for a BSD compatible install... ./install-sh -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... missing
checking whether to enable maintainer-specific portions of Makefiles... no
checking host system type... powerpc-ibm-aix4.3.2.0
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking for bison... bison -y
checking bison version... 1.25 (ok)
checking for gcc... gcc
checking whether the C compiler (gcc -O2 -I/usr/local/ssl/include
-I/usr/local/odbcsdk/include -L/usr/local/ssl/lib -L/usr/local/odbcsdk/lib) works...
yes
checking whether the C compiler (gcc -O2 -I/usr/local/ssl/include
-I/usr/local/odbcsdk/include -L/usr/local/ssl/lib -L/usr/local/odbcsdk/lib) is a
cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... yes
checking for gcc option to accept ANSI C... none needed
checking for ranlib... ranlib
[PHP-DEV] Bug #13783 Updated: odbc_fetch_into different issue
ID: 13783
Updated by: ahill
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: ODBC related
Operating System: SCO Openserver 5.0.5 RH Lnux 7
PHP Version: 4.0.6
New Comment:
Are you getting error messages?
Also, please generate an odbc trace; uncomment the DebugFile section in odbc.ini.
Best regards,
Andrew Hill
OpenLink Software
Previous Comments:
[2001-10-21 20:59:21] [EMAIL PROTECTED]
Platforms:
Using PHP 4.0.6/Openlink 4.1/Progress 8.3D.
Other:
I've tried PHP 4.0.4/4.0.5/4.0.6, Openlink 3.2,4.0,4.1, Progress 8.3C,8.3D,9.1C,
shared memory and TCP/IP based connections.
Problem:
Doesn't seem to matter what I do, I am completely unable to select specific rows using
ODBC.
I think the code below is correct, it's snipped from scripts.
?
$dsn=DSN=$database;UID=$user;PWD=$password;
// I've tried all these without a difference.
$cursor=SQL_CUR_USE_ODBC;
//$cursor=SQL_CUR_IF_NEEDED;
//$cursor=SQL_CUR_USE_DRIVER;
//$cursor=SQL_CUR_DEFAULT;
$sql=SELECT * FROM user_table;
$text=;
function db_fetch_into($id, $number) {
global $text;
$text = TDROW: $number/TD;
//Never Returns Anything
//odbc_fetch_into($id, $number, $result_array);
//Always Works
odbc_fetch_into($id, $result_array);
//Always Works
//odbc_fetch_into($id, 0, $result_array);
return $result_array;
}
if ($conn=odbc_connect($dsn,,,$cursor)){
echo TABLE border='1';
//while ((odbc_fetch_into($results,$pos,$row)) ($count$limit)) {
$pos=0;
while ((list($var1,$var2) = db_fetch_into($result, $pos)) ($pos10)) {
echo TR$textTD$var1/TDTD$var2/TD/TR;
$pos ++;
}
echo /TABLE;
odbc_free_result($result);
odbc_close($conn);
} else {
// No connection .
}
?
Edit this bug report at http://bugs.php.net/?id=13783edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13316 Updated: CGI dies (Premature end of script headers) with URLs with /x after script name
ID: 13316 Updated by: ahill Reported By: [EMAIL PROTECTED] Status: Open Bug Type: URL related Operating System: Windows 2000 SP1 PHP Version: 4.0.6 New Comment: I can conform this also occurs on linux 2.2.19. Best regards, Andrew Previous Comments: [2001-09-15 05:46:35] [EMAIL PROTECTED] I am using the binary from this site. Anytime I access a PHP script with any characters after a / after the script name, it gives me an internal server error 500 and says Premature end of script headers: c:/php/php.exe in the error log. What I mean is if I type http://localhost/script.php/1; it will crash. I want to do this so I can avoid http://localhost/script.php?test=1; for search engines. It works fine in module mode though!! I hope this makes sense...it is hard to explain =) I am using apache 1.3.20. Edit this bug report at http://bugs.php.net/?id=13316edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13312 Updated: cant connect to a odbc source
ID: 13312 Updated by: ahill Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Operating System: Windows2000 server PHP Version: 4.0.6 New Comment: This will occur on Windows if you try to use a File DSN instead of a System DSN - and is expected behavior. Try a System DSN. For people searching the bug list, if you experience this on linux/unix, this will occur if you don't pass the location of your odbc.ini to your script with a putenv(ODBCINI=/path/to/odbc.ini); Best regards, Andrew Hill OpenLink Software Previous Comments: [2001-09-15 04:04:27] [EMAIL PROTECTED] I tried to connect with a Microsoft Access database but it didnt work. I made the DSN named reg and then I used the following code to connect $connection=odbc_connect(reg,admin,) or die (Cant connect the datasource); $sql=Select * from newuser order by name asc; $sql_statement=odbc_prepare($connection,$sql) or die (Cant prepare statement); $sql_result=odbc_execute($sql_statement) or die (Cant execute query); odbc_result_all($sql_result,border=1); odbc_free-result($sql_result); odbc_close($connection); when i view the php page it says Warning: SQL error: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified can anyone solve my problem Edit this bug report at http://bugs.php.net/?id=13312edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11595 Updated: Error in the migration PHP3 to PHP4 with OpenLink-ODBC drive
ID: 11595 Updated by: ahill Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: ODBC related Operating System: Solaris 2.7 PHP Version: 4.0.4pl1 Assigned To: ahill New Comment: Hi, Please try with 4.0.6 or submit an ODBC trace; I am unable to reproduce. Best regards, Andrew Previous Comments: [2001-07-09 16:08:07] [EMAIL PROTECTED] Nico, Can you please generate a trace? I expect we will see a problem in the SQLPrepare where it's dropping your subquery. To enable tracing, add or uncomment the following line in the $ODBCINI file: DebugFile=/tmp/opl_debug.out and then please paste the resultant trace in. Best regards, Andrew Hill OpenLink Software [2001-06-26 17:59:09] [EMAIL PROTECTED] assigning to ahill as he knows openlink best :) [2001-06-21 11:13:00] [EMAIL PROTECTED] Sorry, message error: Warning: SQL error: [OpenLink][ODBC][Driver]General error, SQL state S1000 in SQLPrepare in /psitio/multihomed/www.elsitio.com/pub/cgi-bin/gl/av/player/test.php3 on line 19 The most strange is that I reduce the query string SELECT P.* FROM REAL_CAT_PADRE P WHERE IDIOMA = 'C' AND P.ID_PADRE IN ( SELECT ID_HIJO FROM REAL_CAT_HIJO ) to SELECT P.* FROM REAL_CAT_PADRE P WHERE IDIOMA = 'C' it works fine IN PHP4... I don't know is very strange. Nico. [2001-06-21 11:10:52] [EMAIL PROTECTED] marking as feedback until user responds... [2001-06-21 09:50:44] [EMAIL PROTECTED] Nico, What error to you show? Best regards, Andrew Hill OpenLink Software 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/?id=11595 Edit this bug report at http://bugs.php.net/?id=11595edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11595 Updated: Error in the migration PHP3 to PHP4 with OpenLink-ODBC drive
ID: 11595 Updated by: ahill Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: ODBC related Operating System: Solaris 2.7 PHP Version: 4.0.4pl1 Assigned To: ahill New Comment: Nico, Can you please generate a trace? I expect we will see a problem in the SQLPrepare where it's dropping your subquery. To enable tracing, add or uncomment the following line in the $ODBCINI file: DebugFile=/tmp/opl_debug.out and then please paste the resultant trace in. Best regards, Andrew Hill OpenLink Software Previous Comments: [2001-06-26 17:59:09] [EMAIL PROTECTED] assigning to ahill as he knows openlink best :) [2001-06-21 11:13:00] [EMAIL PROTECTED] Sorry, message error: Warning: SQL error: [OpenLink][ODBC][Driver]General error, SQL state S1000 in SQLPrepare in /psitio/multihomed/www.elsitio.com/pub/cgi-bin/gl/av/player/test.php3 on line 19 The most strange is that I reduce the query string SELECT P.* FROM REAL_CAT_PADRE P WHERE IDIOMA = 'C' AND P.ID_PADRE IN ( SELECT ID_HIJO FROM REAL_CAT_HIJO ) to SELECT P.* FROM REAL_CAT_PADRE P WHERE IDIOMA = 'C' it works fine IN PHP4... I don't know is very strange. Nico. [2001-06-21 11:10:52] [EMAIL PROTECTED] marking as feedback until user responds... [2001-06-21 09:50:44] [EMAIL PROTECTED] Nico, What error to you show? Best regards, Andrew Hill OpenLink Software [2001-06-20 18:27:41] [EMAIL PROTECTED] When I migrated from PHP3 to PHP4 this script didn't work any more. I don't have connection problems and the error appears just in some cases. The following is an ad-hoc script that reproduce the odbc error. // PHP Version 4.0.4pl1 // OS: Solaris 2.7 // Driver: ODBC-Openlink multi-tier 3.2 // this connection works fine. $conn_id = odbc_connect(Driver=/psitio/openlink/odbcsdk/lib/oplodbc.so.1;Host=sql02.local;SVT=SQLServer 7;UID=batalla_web;PWD=mundial86;DATABASE=elsitiodb2;FetchBufferSize=4,,); echo my connection $conn_idBR; $qry = SELECT P.* FROM REAL_CAT_PADRE P WHERE IDIOMA = ' . $idioma . ' . AND P.ID_PADRE IN (SELECT H.ID_HIJO FROM REAL_CAT_HIJO H WHERE . H.ID_PADRE = ' . $cat . ') ; // this query works. $qry = SELECT * FROM REAL_CAT_HIJO; // this query doesn't work IN PHP4 but works fine in PHP3 with the same ODBC-OPENLINK drive(??). $qry = SELECT idvalor,Valor,Tipo_rango FROM Fot_atributo_valor WHERE idcanal=41 AND idaplic=1 AND idatrib=2 ORDER BY idvalor; $res_id = odbc_prepare($conn_id,$qry); // the error occur in this code line (IN PHP4). $result = odbc_execute($res_id); Thanks in advance. Nico. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11595edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11595 Updated: Error in the migration PHP3 to PHP4 with OpenLink-ODBC drive
ID: 11595 Updated by: ahill Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: Nico, What error to you show? Best regards, Andrew Hill OpenLink Software Previous Comments: --- [2001-06-20 18:27:41] [EMAIL PROTECTED] When I migrated from PHP3 to PHP4 this script didn't work any more. I don't have connection problems and the error appears just in some cases. The following is an ad-hoc script that reproduce the odbc error. // PHP Version 4.0.4pl1 // OS: Solaris 2.7 // Driver: ODBC-Openlink multi-tier 3.2 // this connection works fine. $conn_id = odbc_connect(Driver=/psitio/openlink/odbcsdk/lib/oplodbc.so.1;Host=sql02.local;SVT=SQLServer 7;UID=batalla_web;PWD=mundial86;DATABASE=elsitiodb2;FetchBufferSize=4,,); echo my connection $conn_idBR; $qry = SELECT P.* FROM REAL_CAT_PADRE P WHERE IDIOMA = ' . $idioma . ' . AND P.ID_PADRE IN (SELECT H.ID_HIJO FROM REAL_CAT_HIJO H WHERE . H.ID_PADRE = ' . $cat . ') ; // this query works. $qry = SELECT * FROM REAL_CAT_HIJO; // this query doesn't work IN PHP4 but works fine in PHP3 with the same ODBC-OPENLINK drive(??). $qry = SELECT idvalor,Valor,Tipo_rango FROM Fot_atributo_valor WHERE idcanal=41 AND idaplic=1 AND idatrib=2 ORDER BY idvalor; $res_id = odbc_prepare($conn_id,$qry); // the error occur in this code line (IN PHP4). $result = odbc_execute($res_id); Thanks in advance. Nico. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11595edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10549 Updated: Performance problem with Openlink ODBC drivers
ID: 10549 Updated by: ahill Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: this is a workaround for getting around the overhead required when server-side cursor libraries are in use. OpenLink 4.0 implements a mixed cursor library in the server-side components. Server-side cursors should be used sparingly for this reason -Stephen Schadt Previous Comments: --- [2001-05-02 03:22:50] [EMAIL PROTECTED] I'm using the Openlink Data Access Driver Suite (Multi Tier Edition) Version 4.0, Connecting to a Progress 8.3B Database running on an AIX Unix Box. --- [2001-05-01 16:59:38] [EMAIL PROTECTED] before i commit such a patch, what version of OpenLink are you using? --- [2001-04-29 06:35:11] [EMAIL PROTECTED] Hello, I've experienced a compilation error and some huge performance problems setting up an ODBC connection via Openlink ODBC drivers. I've configured my Php: ./configure --with-openlink=/usr/src/openlink When compiling Php, it complains about missing the iodbc.h udbcext.h header files which are not included in the SDK software package of Openlink. When I remove the two above include files from ./ext/odbc/php_odbc.h line 125 128 the compilation works fine without errors or warnings, and am able to etablish a connection to my Openlink drivers. When I query my DB from out of Php via Openlink, a simple query takes huges amounts of time, while the same query is very fast using the included odbctest utility from the Openlink SDK package. I've run a query via Php and the odbctest utility and compared the two debug files and saw that Php uses the ExtendedSQLFetch C- function. The odbctest utility uses an 'normal' SQLFetch function. So I have changed my ./ext/odbc/php_odbc.h file line 124 from: #elif defined(HAVE_OPENLINK) /* OpenLink ODBC drivers */ #define ODBC_TYPE Openlink #include iodbc.h #include isql.h #include isqlext.h #include udbcext.h #define HAVE_SQL_EXTENDED_FETCH 1 #define SQLSMALLINT SWORD #define SQLUSMALLINT UWORD to: #elif defined(HAVE_OPENLINK) /* OpenLink ODBC drivers */ #define ODBC_TYPE Openlink // #include iodbc.h #include isql.h #include isqlext.h // #include udbcext.h // #define HAVE_SQL_EXTENDED_FETCH 1 #undef HAVE_SQL_EXTENDED_FETCH #define SQLSMALLINT SWORD #define SQLUSMALLINT UWORD With this small change I was able to compile my Php succesfully and query my Database via the Openlink Package very fast! Regards, Anne van der Velden Correct Express The Netherlands --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10549edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #8941 Updated: Openlink/ODBC cannot parse complex queries
ID: 8941 Updated by: ahill Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Operating system: PHP Version: 4.0.2 Assigned To: Comments: this issue is specific to the interaction of the Progress database and the OpenLink Agent-based cursor library once scrollable cursors are not used this is not a problem Previous Comments: --- [2001-04-02 17:01:59] [EMAIL PROTECTED] According to openlink, the issue is caused by the dynamic cursors now used in the php odbc functions. remarking out the #define HAVE_SQL_EXTENDED_FETCH 1 entry in the iodbc section provides a temporary relief from the problem. --- [2001-04-02 16:55:47] [EMAIL PROTECTED] have you tried updating to the latest OpenLink libraries? They have supposedly been better enhanced and unified with PHP. --- [2001-02-05 10:36:30] [EMAIL PROTECTED] problem still exists in PHP 404 sp1 --- [2001-01-26 12:27:51] [EMAIL PROTECTED] Configuration above should show PHP4.0.2 not 4.0.1pl2 --- [2001-01-26 12:26:10] [EMAIL PROTECTED] Platform: HPUX 10.20 Configuration: PHP4.0.1pl2 --with-iodbc --without-mysql --with-pdflib=/usr/local --without-gd --with-apache=../apache_1.3.14 Using Openlink MT ODBC driver against a PROGRESS database. Any version of PHP after 4.0.1pl2 cannot parse queries with a JOIN statement in it. Versions upto and including above work ok. The log file from the Openlink Server shows this from a sample (good) query: generic_pro83b: SCR_AnalyseSQL failed: SELECT * FROM VIRTUAL_LAYERS INNER JOIN LAYER_INFORMATION ON LAYER_INFORMATION.LAYER1_DESCRIPTION=VIRTUAL_LAYERS.LAYER1_DESCRIPTION generic_pro83b: parse error generic_pro83b: SELECT * FROM VIRTUAL_LAYERS INNER JOIN^ --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8941edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10369 Updated: Openlink4/ODBC odbc_field_type returns nothing
ID: 10369
Updated by: ahill
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: ODBC related
Operating system:
PHP Version: 4.0.4pl1
Assigned To:
Comments:
Reproduced with the PHP script.
Also reproduced without PHP, using both OpenLink and the Native SQLServer driver.
This is a failure of the database layer to the SQLColAttribute (or SQLColAttributes)
call.
SQLColAttributes:
In: hstmt = 0x008218D8,
icol = 1, fDescType = SQL_COLUMN_TYPE=2, rgbDesc = 0x00154528, cbDescMax = 600,
pcbDesc = 0x001552F0,
pfDesc
= 0x00155E30, Description Type = SQL_C_SLONG=-16
Return: SQL_SUCCESS=0
Out:*rgbDesc = unmodified,
*pcbDesc = 4, *pfDesc = 4
TST1001: Buffer rgbDesc was not updated.
Best regards,
Andrew
Previous Comments:
---
[2001-05-04 15:15:52] [EMAIL PROTECTED]
Firstly, please use --with-iodbc instead of --with-iodbc.
Also, this is most likely not a PHP issue but a database specific issue, and will only
occur in cases where the corresponding database CLI call doesn't work natively.
Please test this with the latest OpenLink drivers and open a support case at
http://www.openlinksw.com/support/suppindx.htm if the problem persists.
---
[2001-04-17 20:12:15] [EMAIL PROTECTED]
This script reproduces the problem:
HTML
HEAD
TITLETest odbc_field_type/TITLE
/HEAD
BODY bgcolor=#00 text=#CC link=#33CCFF vlink=#996699 alink=#FF
marginwidth=0 marginheight=0 topmargin=0 leftmargin=0
?php
putenv(LD_LIBRARY_PATH=/usr/local/openlink/odbcsdk/lib);
putenv(LIBPATH=/usr/local/openlink/odbcsdk/lib:$LIBPATH);
putenv(SHLIB_PATH=/usr/local/openlink/odbcsdk/lib:$SHLIB_PATH);
putenv(UDBCINI=/usr/local/openlink/bin/odbc.ini);
putenv(ODBCINSTINI=/usr/local/openlink/bin/odbcinst.ini);
putenv(ODBCINI=/usr/local/openlink/bin/odbc.ini);
$dsn=DSN=Arbant;
$user=dba;
$password=sql;
$sql='Select cod_emp, cod_amb, den from loguec';
if(($conn_id=odbc_connect($dsn,,))){
if(($result=odbc_prepare($conn_id,$sql))){
@odbc_execute($result);
if(!empty($result)){
$cols_count=odbc_num_fields($result);
$ind=1;
while($ind=$cols_count){
$cols_name[$ind]=odbc_field_name($result,$ind);
$cols_types[$ind]=odbc_field_type($result,$ind);
$ind++;
}
echo H1Results/H1;
echo BThe Query is: $sqlBn;
echo 'TABLE align=center border=1 bordercolor=green cellpadding=
2 cellspacing=0';
$ind=1;
echo trtdbNames/b/tdtdbTypes/b/td/tr;
while($ind=$cols_count){
echo tr;
echo td . $cols_name[$ind] . /tdn;
echo td . $cols_types[$ind] . /tdn;
echo /tr;
$ind++;
}
odbc_free_result($result);
}else{
echo Cannot execute query;
}
}else{
echo Cannot prepare query;
}
}
?
/BODY/HTML
I compiled PHP standard, I simply run ./configure with openlink option , run make and
make install.
I can retrieve column name information and also data but I can't retrieve the column
SQL Type. I asked Openlink and they said that is a PHP issue.
I'm using Openlink Multi-tier Driver for accessing a MS SQL Server 7 Database on a
Windows NT box from PHP scripts running on the Apache Web Server on a Linux Box
OpenLink Version 4
PHP Version 4.0.4pl1
Linix SuSE 6.1 Kernel Version 2.2.7
Apache Version 1.3
PHP is running as a Loadable Apache Module
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10369edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9571 Updated: Undefined symbols in apache build using PHP 4.0.4pl1
ID: 9571 Updated by: ahill Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related PHP Version: 4.0.4pl1 Assigned To: Comments: This is true. To follow the standard more closely we have removed some files and standardized the iODBC Driver Manager SDK. The current SDK is contained here: ftp://www.openlinksw.com/open40/l2ko.taz I did not find that the compile fails however. One reason is probably because using --with-openlink is no longer the recommended option. Using --with-iodbc should work in all cases. Previous Comments: --- [2001-04-16 22:34:28] [EMAIL PROTECTED] can we get one of the OpenLink people to comment on this please? --- [2001-03-16 19:48:56] [EMAIL PROTECTED] Reclassified. --- [2001-03-07 11:54:12] [EMAIL PROTECTED] Many thanks, that did it. 4.0.5 Dev built with: ./configure --with-mysql=/export/db/mysql --with-apache=/export/home/temp/apache_1.3.14 --with-pgsql=/export/home/app/pgsql --with-openlink --with-dom=/usr/local --with-zlib-dir=/usr/local --with-gd=/usr/local --with-xpm-dir=/usr/local --with-t1lib=/usr/local --with-tiff-dir=/usr/local --with-png-dir=/usr/local --with-jpeg-dir=/usr/local --with-pdflib=/usr/local --with-ttf=/usr/local --enable-debug --enable-magic-quotes --enable-libgcc --enable-calendar --enable-ftp --enable-gd-imgstrttf --enable-gd-native-ttf --enable-trans-sid --enable-shmop --enable-track-vars Note that v.4 of the Openlink dirver manager no longer uses (or includes with the distribution) the file iodbc.h. This file has been replaced with sqltypes.h (located in openlink_install_dir/odbcsdk/include). The file php_odbc.h includes iodbc.h at or about line 128, so the build fails. The solution is to remove the reference to iodbc.h. The file sqltypes.h is included within sql.h, which is included within isql.h, which is included at line 129 of php_odbc.h. Placing iodbc.h (from a previous installation, say) into the include directory breaks the build with type definition errors. --- [2001-03-06 06:21:34] [EMAIL PROTECTED] Please try the latest CVS snapshot from http://snaps.php.net/ --Jani --- [2001-03-06 00:43:54] [EMAIL PROTECTED] Same problem as in Bug #9161 - Undefined Symbol errors. ./configure --with-mysql=/export/db/mysql --with-apache=/export/home/temp/apache_1.3.14 --with-pgsql=/export/ home/app/pgsql --with-openlink --with-dom=shared,/usr/local --with-zlib=/usr/local --with-gd --with-tiff-dir=/usr/local --with-jpeg-dir=/usr/local --with-pdflib=/usr/local --with-ttf=shared,/usr/local --enable-debug --enable-magic-quotes --enable-libgcc --enable-calendar --enable-ftp --enable-gd-imgstrttf -- enable-track-vars First was getting errors like: Undefined First referenced symbolin file some_png_symbol modules/php4/libphp4.a(libpng.o) adding --with-gd=shared,/usr/local got past it, but then isinfmodules/php4/libphp4.a(mod_php4.o) after several clean make, clean installs, finally went into config.cache and set isinf to 'no'. Clean make, clean install of PHP, reconfig apache with --activate-module, make and she finally built and started right up. Seems to be some issue with the shared libs also maybe smells like Solaris not having ldconfig? --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9571edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10369 Updated: Openlink4/ODBC odbc_field_type returns nothing
ID: 10369
Updated by: ahill
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: ODBC related
PHP Version: 4.0.4pl1
Assigned To:
Comments:
Firstly, please use --with-iodbc instead of --with-iodbc.
Also, this is most likely not a PHP issue but a database specific issue, and will only
occur in cases where the corresponding database CLI call doesn't work natively.
Please test this with the latest OpenLink drivers and open a support case at
http://www.openlinksw.com/support/suppindx.htm if the problem persists.
Previous Comments:
---
[2001-04-17 20:12:15] [EMAIL PROTECTED]
This script reproduces the problem:
HTML
HEAD
TITLETest odbc_field_type/TITLE
/HEAD
BODY bgcolor=#00 text=#CC link=#33CCFF vlink=#996699 alink=#FF
marginwidth=0 marginheight=0 topmargin=0 leftmargin=0
?php
putenv(LD_LIBRARY_PATH=/usr/local/openlink/odbcsdk/lib);
putenv(LIBPATH=/usr/local/openlink/odbcsdk/lib:$LIBPATH);
putenv(SHLIB_PATH=/usr/local/openlink/odbcsdk/lib:$SHLIB_PATH);
putenv(UDBCINI=/usr/local/openlink/bin/odbc.ini);
putenv(ODBCINSTINI=/usr/local/openlink/bin/odbcinst.ini);
putenv(ODBCINI=/usr/local/openlink/bin/odbc.ini);
$dsn=DSN=Arbant;
$user=dba;
$password=sql;
$sql='Select cod_emp, cod_amb, den from loguec';
if(($conn_id=odbc_connect($dsn,,))){
if(($result=odbc_prepare($conn_id,$sql))){
@odbc_execute($result);
if(!empty($result)){
$cols_count=odbc_num_fields($result);
$ind=1;
while($ind=$cols_count){
$cols_name[$ind]=odbc_field_name($result,$ind);
$cols_types[$ind]=odbc_field_type($result,$ind);
$ind++;
}
echo H1Results/H1;
echo BThe Query is: $sqlBn;
echo 'TABLE align=center border=1 bordercolor=green cellpadding=
2 cellspacing=0';
$ind=1;
echo trtdbNames/b/tdtdbTypes/b/td/tr;
while($ind=$cols_count){
echo tr;
echo td . $cols_name[$ind] . /tdn;
echo td . $cols_types[$ind] . /tdn;
echo /tr;
$ind++;
}
odbc_free_result($result);
}else{
echo Cannot execute query;
}
}else{
echo Cannot prepare query;
}
}
?
/BODY/HTML
I compiled PHP standard, I simply run ./configure with openlink option , run make and
make install.
I can retrieve column name information and also data but I can't retrieve the column
SQL Type. I asked Openlink and they said that is a PHP issue.
I'm using Openlink Multi-tier Driver for accessing a MS SQL Server 7 Database on a
Windows NT box from PHP scripts running on the Apache Web Server on a Linux Box
OpenLink Version 4
PHP Version 4.0.4pl1
Linix SuSE 6.1 Kernel Version 2.2.7
Apache Version 1.3
PHP is running as a Loadable Apache Module
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10369edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9571 Updated: Undefined symbols in apache build using PHP 4.0.4pl1
ID: 9571 Updated by: ahill Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: ODBC related PHP Version: 4.0.4pl1 Assigned To: Comments: Previous Comments: --- [2001-04-16 22:34:28] [EMAIL PROTECTED] can we get one of the OpenLink people to comment on this please? --- [2001-03-16 19:48:56] [EMAIL PROTECTED] Reclassified. --- [2001-03-07 11:54:12] [EMAIL PROTECTED] Many thanks, that did it. 4.0.5 Dev built with: ./configure --with-mysql=/export/db/mysql --with-apache=/export/home/temp/apache_1.3.14 --with-pgsql=/export/home/app/pgsql --with-openlink --with-dom=/usr/local --with-zlib-dir=/usr/local --with-gd=/usr/local --with-xpm-dir=/usr/local --with-t1lib=/usr/local --with-tiff-dir=/usr/local --with-png-dir=/usr/local --with-jpeg-dir=/usr/local --with-pdflib=/usr/local --with-ttf=/usr/local --enable-debug --enable-magic-quotes --enable-libgcc --enable-calendar --enable-ftp --enable-gd-imgstrttf --enable-gd-native-ttf --enable-trans-sid --enable-shmop --enable-track-vars Note that v.4 of the Openlink dirver manager no longer uses (or includes with the distribution) the file iodbc.h. This file has been replaced with sqltypes.h (located in openlink_install_dir/odbcsdk/include). The file php_odbc.h includes iodbc.h at or about line 128, so the build fails. The solution is to remove the reference to iodbc.h. The file sqltypes.h is included within sql.h, which is included within isql.h, which is included at line 129 of php_odbc.h. Placing iodbc.h (from a previous installation, say) into the include directory breaks the build with type definition errors. --- [2001-03-06 06:21:34] [EMAIL PROTECTED] Please try the latest CVS snapshot from http://snaps.php.net/ --Jani --- [2001-03-06 00:43:54] [EMAIL PROTECTED] Same problem as in Bug #9161 - Undefined Symbol errors. ./configure --with-mysql=/export/db/mysql --with-apache=/export/home/temp/apache_1.3.14 --with-pgsql=/export/ home/app/pgsql --with-openlink --with-dom=shared,/usr/local --with-zlib=/usr/local --with-gd --with-tiff-dir=/usr/local --with-jpeg-dir=/usr/local --with-pdflib=/usr/local --with-ttf=shared,/usr/local --enable-debug --enable-magic-quotes --enable-libgcc --enable-calendar --enable-ftp --enable-gd-imgstrttf -- enable-track-vars First was getting errors like: Undefined First referenced symbolin file some_png_symbol modules/php4/libphp4.a(libpng.o) adding --with-gd=shared,/usr/local got past it, but then isinfmodules/php4/libphp4.a(mod_php4.o) after several clean make, clean installs, finally went into config.cache and set isinf to 'no'. Clean make, clean install of PHP, reconfig apache with --activate-module, make and she finally built and started right up. Seems to be some issue with the shared libs also maybe smells like Solaris not having ldconfig? --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9571edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9869 Updated: ODBC - odbc_exec does not seem to work with an Access db
ID: 9869
Updated by: ahill
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: ODBC related
Assigned To:
Comments:
Bruce,
What version of the OpenLink drivers are you using? The problem here is
most likely due to the fact that you're still running Release 3.2 of
OpenLink. The reason Perl works and PHP doesn't is because PHP 4 opens
select statements on server-side dynamic cursors by default. OpenLink 3.2
did not handle this functionality as it should have. You don't really need
this type of cursor, and if you don't want to upgrade OpenLink, we suggest
you disable dynamic cursor functionality in PHP by commenting out all lines
like this:
#define HAVE_SQL_EXTENDED_FETCH 1
in all the PHP include files for ODBC. Of course, this assumes the problem
is happening *after* the query has been executed in your code.
Otherwise, an upgrade to OpenLink release 4.0 drivers would be recommended.
On a related note, one thing we had requested from the PHP development
community was the ability to use the "odbc_setoption" function to modify the
ODBC cursor type *before* the preparation of a query. (I.e. Remove the
necessity to create a $result type object prior to changing the cursor type
of the statement.) This would help in cases where Preparing or Executing
the query is causing database-specific errors because of the dynamic cursor
type.
Regards,
Stephen
OpenLink Software
http://www.openlinksw.com
Previous Comments:
---
[2001-03-26 17:05:25] [EMAIL PROTECTED]
working on something similar already for some of the other bug reports... guess i can
tack this onto the pile as well..
---
[2001-03-20 08:51:49] [EMAIL PROTECTED]
I am unable to use PHP/Openlink ODBC to get specific rows based on my SELECT statement
form a MS Access 97 db. I can use PHP/Openlink just fine while accessing an Informix
db hosted on a SCO box. I can also use Perl/DBI:DBD:ODBC to get the rows I need from
this Access db, so I'm guessing this is a PHP bug. Here is a snipet of the code I
use:
putenv( "ODBCINI=/usr/local/openlink/bin/odbc.ini" );
putenv( "ODBCHOME=/usr/local/openlink" );
putenv( "ODBCINST=/usr/local/openlink/bin/odbcinst.ini");
$conn = odbc_connect("DSN=ink","","", SQL_CUR_USE_ODBC);
$sql = "SELECT DISTINCT * FROM ComponentUse WHERE Code = 'CX145' ";
$cur = odbc_exec($conn, $sql);
// This section of code displayes the tables in the db fine.
$tablelist = odbc_tables($conn);
while (odbc_fetch_row($tablelist)) {
echo odbc_result_all($tablelist);
}
// This section of code does not work - dies with "Driver not capable"
while (odbc_fetch_row($cur)){
$code = odbc_result($cur, "code");
printf ("Code: $coden");
}
odbc_close($conn);
The code will display the table list just fine, but I get the following error from the
odbc_exec statement:
Warning: SQL error: [OpenLink][ODBC][Driver]Driver not capable, SQL state S1C00 in
SQLExecDirect in
/home/httpd/html/ink/dispenser/comp_use.php on line 23
Like I said, I can use Perl/DBD just fine to get the rows I want with that select
statement, so this must be a PHP bug?
Thanks for any help. I really would like to write this application in PHP, since I'm
not too proficient in Perl.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9869edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
