Bug #69438 [Com]: All ODBC return bad values for Cache db
| From: | jason dot maitlen at ontariosystems dot com | Date: | Wed, 23 Nov 2016 20:07:25 +0000 |
| Subject: | Bug #69438 [Com]: All ODBC return bad values for Cache db | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-205583@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=69438&edit=1
ID: 69438
Comment by: jason dot maitlen at ontariosystems dot com
Reported by: keithdavis at solidtechservice dot com
Summary: All ODBC return bad values for Cache db
Status: No Feedback
Type: Bug
Package: ODBC related
Operating System: Windows 7 x64
PHP Version: 5.6.7
Block user comment: N
Private report: N
New Comment:
Unfortunately my solution only worked on numeric fields. For string fields, regardless of how I cast
the field it always returns the string "NEWstrEerror" in varying lengths according to the
length of the actual string.
Previous Comments:
------------------------------------------------------------------------
[2016-11-23 19:20:38] jason dot maitlen at ontariosystems dot com
This is a bit old, but I too am having the same issue where data pulled from a Cache DB is returning
funky characters. In my case it was a numeric field that was returning the garbled data. I examined
the field definition using WinSQL and noticed that it though the numeric field was a varchar. I
added a CAST function in my SQL that converted the (already numeric) field into a numeric. Like
this:
CAST(SomeNumericField AS NUMERIC)
------------------------------------------------------------------------
[2015-05-10 04:22:17] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
------------------------------------------------------------------------
[2015-04-29 10:06:45] ab@php.net
Ok, so this is kinda bad situation as we have no repro to debug on. I can suggest you two things yet
- there was a fix for bug #69381 which might affect / or might not this issue
- please post the trace of what is going on, check that there's no sensitive data in there
Thanks.
------------------------------------------------------------------------
[2015-04-28 21:38:58] keithdavis at solidtechservice dot com
"But look, maybe you can experiment with a simple driver, like Access."
Do you mean that the issue would exist with other ODBC drivers? No, the issue does not with our
other primary ODBC connection (Informix 7 SE).
------------------------------------------------------------------------
[2015-04-22 13:36:50] ab@php.net
You're right, if there's no data behind it, it might not reproduce. But look, maybe you
can experiment with a simple driver, like Access. Or, maybe the driver allows other backends?
As you mean the subject is the column access with specific data types and you were able to reproduce
the same with 5.6.8 and a simple access db, so is the repro. Whereby different drivers might of
course behave different ways, the chances are present. Otherwise, if it's manageable the driver
to support some test backend - even better.
Thanks.
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=69438
--
Edit this bug report at https://bugs.php.net/bug.php?id=69438&edit=1