On Sat, Nov 12, 2011 at 6:15 AM, Peet Grobler <peet@xxxxxxxxxxxx> wrote:
> Not sure if this is the correct mailing list to be asking this question
> but here goes:
>
> I've got a prepared statement.
>
> $stmt = $dbh->prepare ("insert into test values (?, ?)")
> or die ("Error: " . $dbh->error);
> $stmt->bind_param ('ii', $var1, $var2)
> or die ("Error: " . $dbh->error);
> $stmt->execute()
> or die ("Error: " . $dbh->error);
>
> Okay I've taken the "or die" statements and put it into a function
> called 'db_error'. So it looks kinda like this:
>
> or db_error ($dbh, $__FILE__, $__LINE__);
>
> My db error then prints out "$dbh->error" and FILE and LINE variables so
> I know exactly where the error is.
>
> I would, however, love to print out the actual SQL text that failed.
> There's no way to determine it, the closest way I can think of is using
> a $sql variable holding the 'prepare' sql - but that's not what's going
> to the database.
>
> On a mysqli error - I can only see the actual sql that caused the
> problem on the development system, as mysql logging is turned on on
> that. It's not possible to turn on on the live system the overhead would
> probably kill us.
>
> Anyone found a way to do this?
>
> Peet
>
Depends on your overall application design. Meaning if you got
database abstraction layer in place to handle all your DB access or
the code snippet you've provided is used directly in a file. In
either case, the same concept applies but details of approach are
different.
* store the SQL statement string into a variable
* in your error handler, access that variable and send it to where you need to
Thus, this:
> $stmt = $dbh->prepare ("insert into test values (?, ?)")
> or die ("Error: " . $dbh->error);
becomes
$sql = "insert into test values (?, ?)";
$stmt = $dbh->prepare ($sql) or db_error ($dbh, __FILE__, __LINE__, $sql);
function db_error(object $dbh = null, $file, $line, $sql)
{
/* do what you need with it here */
}
> or db_error ($dbh, $__FILE__, $__LINE__);
__FILE__ are reserved keywords __LINE__. If you intended to use
variables represent the similar meaning, the suggested approach would
be $file and $line respectively. It would make things easier to read
and less confusing when you're troubleshooting, IMO.
If you have everything done in classes [1] and put all your DB access
in an abstraction layer class, you can use Exception [2] and get stack
traces [3] to better handle and troubleshoot any errors. [4] is the
non OOP way of error handling, IMO less elegant approach.
Best regards,
Tommy
[1] http://php.net/language.oop5
[2] http://php.net/language.exceptions
[3] http://php.net/exception.gettrace
[4] http://php.net/ref.errorfunc
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
