|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #52658 odbc_fetch_row doesn't fetch memo field
Submitted: 2010-08-20 17:38 UTC Modified: 2020-10-05 08:45 UTC
Avg. Score:4.5 ± 1.0
Reproduced:19 of 21 (90.5%)
Same Version:10 (52.6%)
Same OS:8 (42.1%)
From: cyoung at gcs dot neric dot org Assigned: cmb (profile)
Status: Duplicate Package: ODBC related
PHP Version: 5.3.3 OS: Windows Sever 2008
Private report: No CVE-ID: None
 [2010-08-20 17:38 UTC] cyoung at gcs dot neric dot org
odbc_fetch_row doesn't retrieve a memo field from MS access db.  It does however retrieve all the other fields in the same row successfully.  Without the use of odbc_fetch_row, odbc_result retrieves the memo field exactly as expected.  This obviously poses a problem only when trying to retrieve more than one row in a database, which is usually the case more than not.

Test script:
while(odbc_fetch_row($result)) {
     $newsID = odbc_result($result, "newsID");
     $newsTitle = odbc_result($result, "newsTitle");
     $titleLink = odbc_result($result, "titleLink");
     $brief = trim(odbc_result($result, "brief"));
     $link = $titleLink.$newsID;
     $newsBrief = substr($brief, 0, 75);
     echo "<div id=\"newsLink\" class=\"newsTitle\"><a href=\"$link\" onclick=\"'$link', 'GCSNews', 'width=500, height=400, menubar=no, toolbar=no, resizable=no, top=100, left=200'); return false;\">$newsTitle</a></div>";
     echo "<div class=\"newsBrief\">$newsBrief...</div>";			

Expected result:
I expected the memo field "brief" to be fetched, trimmed, and then a substring of the first 75 characters to be stored in $newBrief and print out followed by ...

Actual result:
when trouble shooting, just echoing $brief showed nothing in the browser.  $brief is an empty string when used in conjunction with odbc_fetch_row.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-08-22 19:47 UTC] cyoung at gcs dot neric dot org
I was able to find a way to fix this "problem" I was having when using odbc_fetch_row with memo fields.  When I connected to the database I used the optional cursor_type parameter.

$cnx = odbc_connect('$databaseName', 'user', 'pass', SQL_CUR_USE_ODBC);

This seemed to allow odbc_fetch_row to retrieve the memo field successfully.  I was getting the error below before inserting the cursor type into odbc_connect.

PHP Warning:  odbc_result() [<a href='function.odbc-result'>function.odbc-result</a>]: SQL error: [Microsoft][ODBC Microsoft Access Driver]Invalid cursor position; no keyset defined , SQL state S1109 in SQLGetData
 [2012-02-15 10:34 UTC] phil at mair dot com
This is unbelievable - Open Source is trying to dislodge MS from it's dominant 
role.  You can't seriously expect to succeed in this objective if a MAJOR BUG ... 
and this is major to anyone trying to develop and support cross-platform 
applications ... like this is still "Status Open" and relying on patches 18 months 
after it was first flagged !!

Get real people !
 [2012-02-15 17:01 UTC]
If MS was actually dominant this bug would have been fixed. Only half-serious 
with that statement. ODBC gets very little use and thus very little attention. It 
is a fringe extension. A minor bug in a fringe extension can go unfixed for a 
very long time unless someone comes along and contributes a clean patch for it. 
You need to understand that Open Source isn't simply a new vendor that replaces 
your old proprietary software vendor. Open Source is a collaborative effort of 
interested parties. Sitting on the sidelines yelling aimlessly has absolutely no 
effect in this scenario.
 [2012-02-15 17:42 UTC] phil at mair dot com
"You need to understand that Open Source isn't simply a new vendor that replaces 
your old proprietary software vendor. Open Source is a collaborative effort of 
interested parties"

... I think you hit the nail on the head.

"Open Source .. a collaborative effort of interested parties" = group of 
enthusiasts who meander through developments doing whatever interests them.

"proprietary software vendor" = a commercial organisation focused on delivering 
a stable, viable product.

I'm not being funny, but for years we have WANTED to encourage our clients to 
move to open source, but unfortunately we can't because its 'random'.  From 
time-to-time an organisation has taken the plunge, and us 3rd party suppliers 
catch the cold.

And you are right ... "Sitting on the sidelines yelling aimlessly has absolutely 
no effect in this scenario" ... but I'm not in the business of writing 
platforms, I never claimed to be, and I don't aspire to it.  What I do want to 
do is write solutions based on solid foundations.  Open Source is still failing 
to deliver 20 years after it's initial promise cos "enthusiasm" alone won't 
bring it home.

I don't want to sound negative, and I do understand the huge effort and 
commitment undertaken ... but I call it as I see it.
 [2012-02-15 17:55 UTC]
Right, so in your case you probably should stick to stuff from proprietary 
software vendors. Our goal has never been to dislodge anybody. Our goal is to 
build a tool that works for us. If you want to use it as well, go for it, if not, 
no problem.
 [2015-05-01 14:19 UTC] isellountos at netintegration dot net
The suggested solution:

$cnx = odbc_connect('$databaseName', 'user', 'pass', SQL_CUR_USE_ODBC);

worked for me.

PHP Version 5.3.8
Windows 2003 Server (yeah, still using that)
IIS 6.0

Thank you.
 [2020-10-05 08:45 UTC]
-Status: Open +Status: Duplicate -Assigned To: +Assigned To: cmb
 [2020-10-05 08:45 UTC]
This looks like a duplicate of bug #45341.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Apr 21 08:01:27 2024 UTC