PHP :: Bug #69438 :: All ODBC return bad values for Cache db
php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #69438 All ODBC return bad values for Cache db
Submitted: 2015-04-13 18:19 UTC Modified: 2015-05-10 04:22 UTC
From: keithdavis at solidtechservice dot com Assigned:
Status: No Feedback Package: ODBC related
PHP Version: 5.6.7 OS: Windows 7 x64
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2015-04-13 18:19 UTC] keithdavis at solidtechservice dot com
Description:
------------
This seems to be only when retrieving data from the Intersystems Cache database system (http://www.intersystems.com/our-products/cache/cache-overview/). 

Works fine in 5.6.6, but in 5.6.7, odbc_fetch_array() returns bad values (corrupt / garbled) data for all "string" columns (or any other ODBC function that returns string values).

Tried to paste a sample of what the values it returns, but the values won't even paste in the text box (character set maybe?)

I don't have any problems using ODBC in 5.6.7 with other systems (Informix SE 7 even, which is very old).

I can show screenshots? How best to do that for these bug reports?


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-04-13 18:25 UTC] keithdavis at solidtechservice dot com
-Summary: All ODBC return bad values for Cache +Summary: All ODBC return bad values for Cache db
 [2015-04-13 18:25 UTC] keithdavis at solidtechservice dot com
Modified summary
 [2015-04-14 06:26 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2015-04-14 06:26 UTC] ab@php.net
Please check with the bug #69354 and the latest snapshots. If it doesn't appear to be fixed in the latest snaps, we'll need a reproduce code and the driver.

Thanks.
 [2015-04-15 17:58 UTC] keithdavis at solidtechservice dot com
-Status: Feedback +Status: Open
 [2015-04-15 17:58 UTC] keithdavis at solidtechservice dot com
Strange, but I searched for other ODBC issues and did not see that one - I'd be willing to bet that is the problem.

I tried to test with snapshot r272805c, but that build is broken (the ZIP file is corrupt or not an archive).
 [2015-04-15 20:31 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2015-04-15 20:31 UTC] ab@php.net
Yeah, then please take some later.

Thanks.
 [2015-04-20 15:02 UTC] keithdavis at solidtechservice dot com
I just tested 5.6.8 and the issue is not fixed.
 [2015-04-22 06:26 UTC] ab@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

I can only repeat - please add reproduce sample (also for the driver setup), please test the latest snapshot :) Otherwise there will be no progress here.

Thanks.
 [2015-04-22 11:19 UTC] keithdavis at solidtechservice dot com
I can't provide the database as it's provided by a vendor and ODBC is the only access that I have, plus the database itself is not a SQL database, but only presents a SQL ODBC interface programmatically. I doubt providing the PHP script only (and the driver would provide any benefit.
 [2015-04-22 13:36 UTC] 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.
 [2015-04-28 21:38 UTC] 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-29 10:06 UTC] 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-05-10 04:22 UTC] 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.
 [2016-11-23 19:20 UTC] 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)
 [2016-11-23 20:07 UTC] jason dot maitlen at ontariosystems dot com
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.
 
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Tue Aug 14 08:01:25 2018 UTC