Bug #69438 [Com]: All ODBC return bad values for Cache db

From: 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

« previous php.bugs (#205583) next »