[PHP-DEV] PHP 4.0 Bug #10192: sybase_query with sybase_fetch_row displays real data type incorrectly

2001-04-05 Thread dave . berndt

From: [EMAIL PROTECTED]
Operating system: Linux Mandrake (redhat) 7.0
PHP version:  4.0.3pl1
PHP Bug Type: Sybase (dblib) related
Bug description:  sybase_query with sybase_fetch_row displays real data type 
incorrectly

Queries that produce incorrect data is random, but will consistently happen within a 
particular query.  In one case, the last value of a fetched row (a real), in the last 
row was "1" in the database, but the returned array always displayed "0".  In another 
case, a value (a real) in the middle of the returned array in the database was 
supposed to be "65000" but the fetched array contained "0".  In both cases I copied 
the query from the code EXACTLY and ran it in isql and those results were correct.  So 
the errors are occuring somewhere in php land.  This error seems serious since no 
errors/messages are produced, but the data displayed is incorrect.  Sybase's real data 
type is machine-dependent, and my database is on a Solaris system.  But if isql on my 
linux php machine fetches data correctly, I would expect php to be able to do the same.

Complied with: 
--with-apxs=/usr/sbin/apxs
--with-sybase=/opt/sybase
--without-mysql
--with-layout=RedHat
--enable-shared=max


-- 
Edit Bug report at: http://bugs.php.net/?id=10192edit=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]




Re: [PHP-DEV] PHP 4.0 Bug #10192: sybase_query with sybase_fetch_row displays real data type incorrectly

2001-04-05 Thread Dean Bennett

Try this patch, which also adds support for FLT8.  Also, this applies to 
both PHP3 and PHP4, and the sybase_ct functions don't have this problem.

--- sybase.c.orig   Mon Feb  7 16:54:51 2000
+++ sybase.cMon Apr  3 12:12:00 2000
@@ -635,9 +640,13 @@
 result-type = IS_STRING;
 break;
 }
-   /*case SYBFLT8:*/
+   case SYBFLT8:
+   result-value.dval = *(DBFLT8 
*)dbdata(sybase_ptr-link,offset);
+   result-type = IS_DOUBLE;
+   break;
+
 case SYBREAL: {
-   result-value.dval = (double) floatcol(offset);
+   result-value.dval = (double)(*(DBREAL 
*)dbdata(sybase_ptr-link,offset));
 result-type = IS_DOUBLE;
 break;
 }


At 08:06 PM 05/04/01 +, [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED]
Operating system: Linux Mandrake (redhat) 7.0
PHP version:  4.0.3pl1
PHP Bug Type: Sybase (dblib) related
Bug description:  sybase_query with sybase_fetch_row displays real data 
type incorrectly

Queries that produce incorrect data is random, but will consistently 
happen within a particular query.  In one case, the last value of a 
fetched row (a real), in the last row was "1" in the database, but the 
returned array always displayed "0".  In another case, a value (a real) in 
the middle of the returned array in the database was supposed to be 
"65000" but the fetched array contained "0".  In both cases I copied the 
query from the code EXACTLY and ran it in isql and those results were 
correct.  So the errors are occuring somewhere in php land.  This error 
seems serious since no errors/messages are produced, but the data 
displayed is incorrect.  Sybase's real data type is machine-dependent, and 
my database is on a Solaris system.  But if isql on my linux php machine 
fetches data correctly, I would expect php to be able to do the same.

Complied with:
--with-apxs=/usr/sbin/apxs
--with-sybase=/opt/sybase
--without-mysql
--with-layout=RedHat
--enable-shared=max


--
Edit Bug report at: http://bugs.php.net/?id=10192edit=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 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]