fetchInto DB query error message -- solved

Help
Eric Woods
2004-09-03
2013-04-11
  • Eric Woods

    Eric Woods - 2004-09-03

    I am posting this message to help people who encounter what I did and in the hope that Marco will come up with a good solution for the underlying issue.

    Myself and others have had an error appear that begins:
    "Fatal error: Call to undefined function: fetchinto()"

    After considerable searching I discovered that the problem isn't that fetchinto is not a known function (implying that the PEAR & DB installations aren't working right), but that there is an error in the SELECT statement.  What happens is that in layersmen-common.inc.php (around line 670 in the 3.1.5 version I have) $dbresult is set using...

      $dbresult = $db->query(....)

    and then it is not checked whether the $dbresult has an error.  So, when you get to

      while ($dbresult->fetchInto....

    just below it and you had an error, $dbresult is a DB error object, not a DB result set.  And, indeed, that error object does not have a fetchInto function.

    So, my hack solution for the moment is to add this before the while statement:

      if (DB::isError($dbresult)) {
        print "<pre>"; print_r($dbresult); print "</pre>"; die;
      }

    This gives me the select statement that had been used (very helpful) and the error message from the database, among other things.  Of course, I only want that code in there during my development, since it kills the rest of the page, but at least I know what is really going wrong.

    Marco, you've got an error check after getting the connection ($db = DB::connect(...)), and my presumption is that a similar check after getting $dbresult is what is needed.  I didn't have time to get into whether I could use the existing error reporting mechanisms to solve this elegantly, but I hope that by bringing it to your attention you might have time to provide the well-considered code.

    I think that if this error trap is in place it will prevent the kind of difficulties and recriminations that were reported in previous forum listings (search on "fetchinto").

    In other respects PHP Layers Menu has worked quite well for me.  Thanks, Marco!

     
    • Marco Pratesi

      Marco Pratesi - 2004-09-03

      > in the hope that Marco will come up with a good solution
      > for the underlying issue

      Let me start clarifying that, by now, I am not convinced
      that there is any issue to be fixed and I am also rather
      amazed about all this hassle about such an elementary
      thing as using a PEAR DB connection.
      If I had problems in setting up a PEAR DB connection
      with an opensource package, I surely would not
      immediately post complains to the project's forum.

      >After considerable searching I discovered

      No particular search is needed to realize this:
      just search for "fetchinto" in the directory
      where you have installed PEAR DB, and you can
      immediately realize that the only way for fetchinto
      (that is more correctly named "method" rather than
      "function") to be not defined ("not known")
      is that you do not have installed PEAR DB at all;
      but, in this case, the execution would simply die
      when trying to require_once DB.php.

      > Marco, you've got an error check after getting the connection
      > ($db = DB::connect(...)), and my presumption is that a similar
      > check after getting $dbresult is what is needed.

      I am not convinced of your statement, please let us
      better clarify why an error check should be put there.

      The only thing that is done after the previous error check
      is just a query; the only thing that can fail is just
      that query; why should that query contain an error?
      That query is not intended to be modified
      and it is a very simple query; when may it fail?

      As an example, it can fail if you have created the DB
      but you do not have populated it.
      For everything holy in this world, please let me know,
      do you consider a reasonable behaviour posting
      to the public help forum without having even checked
      if the DB has been correctly created and populated?
      I would never post to a help forum for such a thing,
      at least to avoid a poor figure on a public forum.

      As another example, the query can fail because
      you have changed it and you do not have done
      anything to accurately check *which* query
      is executed once the class code has been modified.
      Well, OOP also implies that the code of objects has not
      to be changed, and, anyway, before posting a help
      request at this regard, you should at least point out
      that you are not using the released code, but a modified
      (and untested) version of it. Also in this case, I would
      play a lot with my custom changes before posting
      a help request on the project's forum.

      Do you know other cases where the query can fail
      even though the user has not done some really
      dummy errors?
      If there are, then please let me know.
      If there are not any such cases, then IMO
      such an error check could be useful but
      is not mandatory.

      Marco Pratesi

       
      • Eric Woods

        Eric Woods - 2004-09-03

        I have had no problem with my PEAR DB connection.  I have not modified the PHP Layers Menu code.  There is no error in the code that I am revealing.  There is simply an opportunity to improve a small part that has caused several people to follow a longer debugging path than necessary.  Perhaps I will make this clear, perhaps not.

        Now, you state "the only way for fetchinto... to be not defined... is that you do not have installed PEAR DB at all".  Well that's not actually true.  A method called on an object that does not contain that method will produce that kind of error.   From whence came the source of this thread.  The object referenced at the point of the call to fetchInto in the case of query error is not a successful query result, it is an error result.  My PEAR DB installation was working just fine (indeed, modifying my connection information to intentionally erroneous values proved that).

        The reason that query can fail (and produce an error) is that the setTableFields method can alter the contents of that select statement.  In my case, a simple typo in a field name was the error.  I have not modifed the PHP Layers Menu source code.  I hadn't even considered that.  I was sure the error was due to my own issue.  It would have helped to know that the issue was in the select statement.

        What I have attempted to suggest is that if you add a couple lines for an error trap (perhaps as simple as the one you have just above it), you can alert a developer to the fact that there was a problem in the select statement caused by their own folly.  Indeed the offending select statement is available in the error response object and upon reviewing it the problem should be fairly visible.  If you provide that select statement in the error output, it would save hapless programmers some time.

        Now, having addressed the factual aspects of your post, I cannot help but respond to the inflamatory aspects.  It is truly ironic, even ridiculous, that after the kind of flames you throw on this forum that you have a statement suggesting one should be cautious to "avoid a poor figure on a public forum."  The way you have treated me with a pompous attitude and insulting comments is truly a "poor figure" to have.  It dimishes you very much.

         
      • mr rowi

        mr rowi - 2006-08-08

        Hi, there is another case where the query fails. This is the case for those people who use a microsoft sql server with PEAR DB. The error about 'fetchInto...' occurs because the query has an ORDER BY clausule which acts on the column named 'text'. Because this column is of the type 'text', it cannot be sorted on by mssql and thus returns an error. But if you change the column type to 'varchar(255)', it works fine.

         
    • Marco Pratesi

      Marco Pratesi - 2004-09-03

      > I have had no problem with my PEAR DB connection.
      > I have not modified the PHP Layers Menu code.
      > There is no error in the code that I am revealing.

      In fact, try to read all help posts in this forum
      about this topic and you will note that *everyone*
      that has posted problems has made dumb errors.

      > There is simply an opportunity to improve a small part
      > that has caused several people to follow a longer
      > debugging path than necessary.

      "debugging" is a big word in this case :-)
      Everyone that would have made "debugging"
      would have solved the problem in an amount of time
      very smaller than the time spent to carry on a thread
      about this topic.

      Anyway, I have replied "IMO such an error check
      could be useful but is not mandatory"; I'm not english
      mother tongue, but, in my mother tongue, this sounds as
      "it is useful, it can be an improvement, I can consider
      this change, but it is not something mandatory".
      In short, I agree that it can be useful, I do not agree
      that it is needed for a user that knows the tools
      he is using.

      > Now, you state "the only way for fetchinto...
      > to be not defined... is that you do not have installed
      > PEAR DB at all". Well that's not actually true.
      > A method called on an object that does not contain
      > that method will produce that kind of error.

      I fear that me not being english mother tongue
      and me not having the possibility of spending hours
      to reply to a posting can cause understanding problems...

      Well, I try to say it in another way.

      There are only two chances:

      1 - you have installed PEAR DB

      2 - you do not have installed (correctly) PEAR DB

      In case 2, you *cannot* get that error, OK?
      If you do not have installed PEAR DB, the execution
      dies *before*, just in *your* script, when you try
      to require_once DB.php, hence you do not even
      go on to the point where you begin using phplm;
      if you have not correctly set up the connection,
      then the execution dies before, right?
      Well, on this forum I have been flamed even
      because I have pointed out this statement!

      In case 1, you can get that error if you write code
      with an error, i.e. if you write code that calls
      that method for an object that does not foresee
      that method.
      But you are not writing fresh code, you are
      *using* the phplm code, hence, unless phplm
      contains such a goofy error that I have used
      fetchinto for an object that does not foresee
      any fetchinto method, then it's your error.
      In such a case, I would simply search
      for the "fetchinto" word into the phplm code
      and into the pear db code, and I would immediately
      understand where the error is.
      BTW, you do not have to be a hacker to put
      a "print" before the query() method to understand
      which query you are passing to the backend :-)
      BTW2, try to search for "pear db tutorial" on google
      and you will see that this is the first search result:
      http://vulcanonet.com/soft/?pack=pear_tut
      where the error check you have proposed
      is not foreseen :-)

      > I was sure the error was due to my own issue.

      Just as I usually do when I use packages written
      by someone else.

      > It would have helped to know that the issue
      > was in the select statement.

      The select statement is the only thing between
      the previous error check and the fetchinto call;
      the issue cannot be elsewhere.

      > What I have attempted to suggest is that if

      And I have appreciated your proposal, I have also
      replied that this could be useful.
      The thing I dislike is that your post has sounded
      to me as if it was an open issue at this regard
      in the package and as if it was normal such an amount
      of postings about PEAR DB in this forum.
      I have even read someone that would want
      a step-by-step guide at this regard in the manual,
      well, sorry, this would be sensed if it was a
      manual/tutorial about PEAR DB, but obviously it is not.

      W.r.t. the flaming part of your post, sorry, but I do not
      agree at all.

      > The way you have treated me with a pompous attitude

      I suppose that you have misunderstood what I have said.
      I have not said that *you* have made a poor figure.
      But please read attentively all the other threads that have
      been posted about PEAR DB in this forum and please
      find at least a case in which the problem has not been
      due either to dumb errors or to being a PHP/PEAR newbie.
      Well, before posting a help request, one should try a bit
      to investigate and solve the problem.
      If instead the problem is due to being a newbie
      in PHP/PEAR, then, sorry, this is not the most useful place
      to learn about PHP and PEAR: pretending such a thing
      would be just as pretending that kernel.org becomes
      a place for discussions about C for C newbies,
      and this would not be sensed.

      Please also consider also the following aspect.
      Another problem that I see: too many people,
      when posting help requests, are not providing
      any informations about what they are doing exactly,
      many do not even specify if they have the problem
      either with the examples in the package or with
      another script they are trying to write.
      If the problem is due e.g. to an error in the field names,
      but the reporter does not point out me that he is using
      a custom table named [...] with the following custom
      DB structure [...] and with the following code [...],
      I cannot know what is going on, as I do not have
      a crystal gazing.
      If instead the reporter provides such informations,
      very probably, just when writing the report, he can
      realize that there is a typo error.
      In short, a correct approach to posting reports
      would avoid completely such a report.
      This is one of the reasons why some time ago
      I was meditating about preparing a document to specify
      how to write a report to be posted on the forum.
      And probably I will really have to do just this, because
      replying to reports is just requiring me *too much* time,
      much more than the time I really have, so that
      this is probably the only alternative to stop
      replying to posts that are not complete, or that are not
      clear, or that are not in topic, or that have posted
      too much in a hurry, and so on, and to be even
      flamed if I make the reporter note the defects in his message.
      Maybe a total absence of reply (just how it happens
      elsewhere in such cases>:-) would be considered
      more educated and more useful :-)

      Marco Pratesi

       
    • Anonymous - 2007-01-21

      Eric Woods said:
      "Now, having addressed the factual aspects of your post, I cannot help but respond to the inflamatory aspects. It is truly ironic, even ridiculous, that after the kind of flames you throw on this forum that you have a statement suggesting one should be cautious to "avoid a poor figure on a public forum." The way you have treated me with a pompous attitude and insulting comments is truly a "poor figure" to have. It dimishes you very much."

      I totally agree. This been said, Marco, you seems totally convinced that there [[can’t]] be any bugs in your code and there only dumb people here. Fine! Everybody can leave with that.

      I would like to presume the attitude you let everyone see is strictly exploited to draw some attention on yourself, but just in case you’re terribly ill, my recommendation to you will be that you withdraw your project if you are not able to deal respectfully using civilized manners in regard to others ideas or matters.

      Your repetitive behaviours toward those unfortunate individuals which in good faith ventured themselves in testing your project does not have any equivalence nowhere on the Web nor here on Sourceforge.net.

      Few human being are exceptionally talented and able to really achieve shining things, but totally unable to interact with others. Very distinctively you are one of those.

      The list of peoples you have verbally abused or excessively turn in ridicule that didn’t deserve it at all has reached a point where something needs to be done against you. I have documented your unacceptable behaves in responses to many people and filed a complaint against you using Sourceforge Reporting Sensitive Issues Procedure.

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks