4

I found same question here but it unanswered, and i provide more simple example here, and try ask again...

Code:

<?php
$dbh = new PDO('mysql:dbname=test;host=127.0.0.1', 'root');
$sth = $dbh->prepare("
    SELECT '
        Dumps the informations contained by a prepared statement directly on the output. It will provide the SQL query in use, the number of parameters used (Params), the list of parameters, with their name, type (paramtype) as an integer, their key name or position, and the position in the query (if this is supported by the PDO driver, otherwise, it will be -1).
        This is a debug function, which dump directly the data on the normal output.
        Tip:
        As with anything that outputs its result directly to the browser, the output-control functions can be used to capture the output of this function, and save it in a string (for example).
        This will only dumps the parameters in the statement at the moment of the dump. Extra parameters are not stored in the statement, and not displayed.
    '
");
$sth->execute();
$sth->debugDumpParams();

Result:

SQL: [835] 
    SELECT '
        Dumps the informations contained by a prepared statement directly on the output. It will provide the SQL query in use, the number of parameters used (Params), the list of parameters, with their name, type (paramtype) as an integer, their key name or position, and the position in the query (if this is supported by the PDO driver, otherwise, it will be -1).
        This is a debug function, which dump directly the data on the normal output.
        Tip:
        As with anythi
Params:  0

Why it occurs, and how fix it?
Thanks in advance!

Community
  • 1
  • 1
cn007b
  • 16,596
  • 7
  • 59
  • 74
  • 3
    I was digging a little through the source and while I was unable to find **exact** answer, I was able to confirm that it does indeed cut all queries at 500 characters. From looking at the source, there is no way around it since the method accepts no parameters and it just writes to output stream using an internal method that you can't "control" with outside parameters. Your only option is to use MySQL and to turn `GENERAL_LOG` to on and capture actual data sent to MySQL that way (which is what I usually do, I never used PDO for debugging). – N.B. Apr 02 '15 at 11:12
  • 1
    Already created bug, https://bugs.php.net/bug.php?id=69356 Hope guys fix it. – cn007b Apr 02 '15 at 11:50
  • But if you think about it, why would you need the query? You already have it, since you're the one who passed it to `prepare`. Your original question also has the query in the variable. The only interesting output of `debugDumpParams` are the parameters, not the actual query. – N.B. Apr 02 '15 at 12:12
  • It good option when write new code. But when i have already written project, and i want to see all queries on page (that already written). It isn't a solution. – cn007b Apr 02 '15 at 12:40
  • But you can't ask PHP maintainers to modify PDO code so you can fetch the string that represents your query. You already gave those query strings to PDO at one point, it should be your responsibility to be able to retrieve them. Reasoning that you need to write new code is simply not good. If I maintained PDO, I wouldn't consider this a bug nor a proper feature. You need to be a responsible developer who has control of your code. This whole issue is easily fixed *at your side*. I know this isn't what you want to read, but that's a fact sadly. – N.B. Apr 02 '15 at 12:50
  • You absolutely right, and i absolutely agree with you. And i think if guys from php don't do this yet - means it has a good reason. But i also think, that it's widely spreaded problem, and it cost nothing for me to write a bug, maybe i'm lucky, and they consider this.) – cn007b Apr 02 '15 at 13:26
  • I looking now to decorator or wrapper to PDO, maybe it will help to see all queries, because rewrite all code - it's that what i want less of all) – cn007b Apr 02 '15 at 13:31
  • May I be so bold and [suggest this project](https://github.com/illuminate/database) for you to look at? I find it's usually much easier to use existing tools that do the job than create your own. I've been using that one instead "raw" PDO for a while now, and I must say it really, really cuts down development time, plus you get good debugging tools for your queries. – N.B. Apr 02 '15 at 13:41
  • 1
    A query can be huge. You can even inject some MBs of binary data into it and —trust me— that can make the browser stop responding. It's normal that a logging facility puts a limit somewhere. – Álvaro González Aug 30 '16 at 07:04
  • @ÁlvaroGonzález i believe you that query can be huge, but anyway i need to see it... – cn007b Aug 30 '16 at 07:44

2 Answers2

3

I think that debugDumpParams is a misfeature at whole. The fact it spits the data right in the standard output alone!

So I wouldn't use it anyway, and for the logging purpose either enable a general log for mysql, or create a wrapper around PDO with logging feature (this solution is more portable).

Your Common Sense
  • 156,878
  • 40
  • 214
  • 345
0

Why it occurs? - I didn't find any info about it.
How fix it? - I didn't find any clue how to fix it using native PDO.

The main purpose of this question - is how to see all queries for certain php script,
and I found only one way to achieve this - is to enable general log for mysql.

cn007b
  • 16,596
  • 7
  • 59
  • 74