Modified summary

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.

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).

Yeah, then please take some later.

Thanks.

I just tested 5.6.8 and the issue is not fixed.

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.

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.

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.

"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).

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.

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.

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)

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.