note 110207 added to function.odbc-num-rows

When accessing a DB2 database with PHP via the ODBC functions, beware of statements which include references to IBM's LONGDESCRIPTION table (for example, if you were - like myself - digging through IBM's Maximo product). Reading from that table usually requires error suppression, because although it works ODBC will spit out a warning message onscreen. When you make it part of another query however, ODBC_NUM_ROWS will always return -1. The solution is to keep any queries to LONGDESCRIPTION in a separate standalone query by itself. However, if you run the query though a previewer like Toad for DB2, using LONGDESCRIPTION in a larger query is fine and does show the results. It's just that you have to break the query up and segregate the query to LONGDESCRIPTION on its own if you are writing ODBC queries for PHP. Just a quick note for anyone else who found ODBC_NUM_RESULTS normally reliable otherwise but inexplicably always returning -1 under certain circumstances. ---- Server IP: 69.147.83.199 Probable Submitter: 175.140.255.125 ---- Manual Page -- http://www.php.net/manual/en/function.odbc-num-rows.php Edit -- https://master.php.net/note/edit/110207 Del: integrated -- https://master.php.net/note/delete/110207/integrated Del: useless -- https://master.php.net/note/delete/110207/useless Del: bad code -- https://master.php.net/note/delete/110207/bad+code Del: spam -- https://master.php.net/note/delete/110207/spam Del: non-english -- https://master.php.net/note/delete/110207/non-english Del: in docs -- https://master.php.net/note/delete/110207/in+docs Del: other reasons-- https://master.php.net/note/delete/110207 Reject -- https://master.php.net/note/reject/110207 Search -- https://master.php.net/manage/user-notes.php