|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #10192 sybase_query with sybase_fetch_row displays real data type incorrectly
Submitted: 2001-04-05 16:06 UTC Modified: 2001-06-12 18:25 UTC
From: dave dot berndt at frco dot com Assigned:
Status: Closed Package: Sybase (dblib) related
PHP Version: 4.0.3pl1 OS: Linux Mandrake (redhat) 7.0
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: dave dot berndt at frco dot com
New email:
PHP Version: OS:


 [2001-04-05 16:06 UTC] dave dot berndt at frco dot com
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: 


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2001-06-12 17:42 UTC]
Does this happen with PHP 4.0.5 ?

 [2001-06-12 18:23 UTC] dave dot berndt at frco dot com
I don't know if it occurs with 4.0.5.  I tested through 4.0.4pl1 at the time of the posting.  Here's the solution I recieved from Dean B.  I assumed he posted it to this Bug report.  He didn't, so here it is:

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.c    Mon Apr  3 12:12:00 2000
@@ -635,9 +640,13 @@
                         result->type = IS_STRING;
-               /*case SYBFLT8:*/
+               case SYBFLT8:
+                       result->value.dval = *(DBFLT8 
+                       result->type = IS_DOUBLE;
+                       break;
                 case SYBREAL: {
-                       result->value.dval = (double) floatcol(offset);
+                       result->value.dval = (double)(*(DBREAL 
                         result->type = IS_DOUBLE;

I tried to migrate to the ct version (compiled and executed fine) but had issues with some sort of link index error with my code.  So I decided to delay migration for now.  THIS case can be closed.

 [2001-06-12 18:25 UTC] dave dot berndt at frco dot com
Bug closed.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Mon Jun 05 06:03:39 2023 UTC