php-general Digest 16 May 2011 22:10:21 -0000 Issue 7313
Topics (messages 312803 through 312815):
Re: PHP want not write in Database
312803 by: Silvio Siefke
312804 by: Stuart Dallas
312805 by: Silvio Siefke
312806 by: Stuart Dallas
312807 by: Silvio Siefke
mysql insert internal server error 500
312808 by: Grega Leskovšek
312809 by: Bálint Horváth
Wierd cookie behaviour
312810 by: Geoff Lane
Re: Functions/methods aliases in PHp 5.2
312811 by: David Harkness
Re: Error recovery - fatal errors
312812 by: David Harkness
312813 by: Tim Streater
312814 by: Peter Lind
312815 by: Tim Streater
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
Hello,
On Mon, 16 May 2011 09:57:23 +0800 xianhua zhou wrote:
> VALUES(:autor, :title, :teaser, :teaser, :content, :category, :bild)
>
> There are 2 ":teaser", try remove one.
Yes thats it. Now it work well done! Thank you, im sorry sure was to long at
the pc yesterday.
Silvio
--- End Message ---
--- Begin Message ---
On Mon, May 16, 2011 at 10:30 AM, Silvio Siefke <[email protected]>wrote:
> Hello,
>
> On Mon, 16 May 2011 09:57:23 +0800 xianhua zhou wrote:
> > VALUES(:autor, :title, :teaser, :teaser, :content, :category, :bild)
> >
> > There are 2 ":teaser", try remove one.
>
> Yes thats it. Now it work well done! Thank you, im sorry sure was to long
> at
> the pc yesterday.
In order to avoid this problem in future I encourage you to check the return
value of every function call you make that might fail, i.e. every single
one! Had you done that here, and then pulled out the last error message from
PDO you would not have had this problem for longer than a minute.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
Hello,
On Mon, 16 May 2011 11:06:17 +0100 Stuart Dallas wrote:
> In order to avoid this problem in future I encourage you to check the return
> value of every function call you make that might fail, i.e. every single
> one! Had you done that here, and then pulled out the last error message from
> PDO you would not have had this problem for longer than a minute.
im sorry, but what u mean? Can u give example. I really starting with PHP
and when have error messages in log there is no problem for me, i can fix the
mistakes in script, but when php write no messages to log i not know where
should search.
I has try with xdebug, but this want not work or i understand it wrong. And
which ways for debug give in PHP?
Regards
Silvio
--- End Message ---
--- Begin Message ---
On Mon, May 16, 2011 at 11:40 AM, Silvio Siefke <[email protected]>wrote:
> Hello,
>
> On Mon, 16 May 2011 11:06:17 +0100 Stuart Dallas wrote:
> > In order to avoid this problem in future I encourage you to check the
> return
> > value of every function call you make that might fail, i.e. every single
> > one! Had you done that here, and then pulled out the last error message
> from
> > PDO you would not have had this problem for longer than a minute.
>
> im sorry, but what u mean? Can u give example. I really starting with PHP
> and when have error messages in log there is no problem for me, i can fix
> the
> mistakes in script, but when php write no messages to log i not know where
> should search.
>
> I has try with xdebug, but this want not work or i understand it wrong. And
> which ways for debug give in PHP?
>
Not all functions raise PHP errors when they fail, in fact most don't. Most
will return an error value, and a few throw exceptions.
As the manual states, the execute method you're using will return true if it
succeeded or false if it failed (http://php.net/pdostatement.execute). You
can then use the errorInfo method to get details of the actual error (
http://php.net/pdostatement.errorinfo).
The best piece of advice I can give you if you're just starting out is...
only ever assume that all of the code you write will fail, and make sure it
handles failures appropriately. Any other assumptions are likely to come
back and bite you on the arse one way or another.
Oh, and read the manual entry for every function, class and method you're
using thoroughly!
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
Hello,
On Mon, 16 May 2011 12:07:37 +0100 Stuart Dallas wrote:
> Not all functions raise PHP errors when they fail, in fact most don't. Most
> will return an error value, and a few throw exceptions.
>
> As the manual states, the execute method you're using will return true if it
> succeeded or false if it failed (http://php.net/pdostatement.execute). You
> can then use the errorInfo method to get details of the actual error (
> http://php.net/pdostatement.errorinfo).
>
> The best piece of advice I can give you if you're just starting out is...
> only ever assume that all of the code you write will fail, and make sure it
> handles failures appropriately. Any other assumptions are likely to come
> back and bite you on the arse one way or another.
>
> Oh, and read the manual entry for every function, class and method you're
> using thoroughly!
thanks i will do it but the most of the manual will not understand direct,
that will come with time. I have read the manual for PDO, so that i can use
it. Before i has my Script with mysqli, but i have read from Prepared
Statemants and that they more comfortable and secure and so i has write. All
was good, only that not want write in database.
Okay thanks all, and im sorry that i disturb with the easy questions. All
mistakes in the script i has found with google and the manual, but when not
give message, there is problem. Often i not know the correct word which should
use to search.
For example i have a HTML Table, in this are much Code for calculate the
Stock Portfolio. <Value, Dividend, Win, Lose> Thats okay, but i search a
function with can tell php that should calculate all data in table. At moment
i have write much Variables for every stock which is in Portfolio. Better
were that i can copy the mathematical formula from one row/cell in next
row/cell, like in excel. That i not found, because i not know what is the
right words for searching.
I dont know understand what i mean? My English not the best.
Thanks for time and help.
Silvio
--- End Message ---
--- Begin Message ---
$ime=$_COOKIE['user'];
$dolgF=filesize($filename)
INSERT INTO `friendlyCMS`.`log` (`imepriimek`, `clock`, `action`,
`onfile`, `filesize`) VALUES ( $ime, CURRENT_TIMESTAMP,
'saved',$filename, $dolgF);
What is wrong with this?
PS First column of the log table is idlog primary key autoincrement
not null - I suppose I omit this when adding to table?
Thanks in advance, Grega
-- When the sun rises I receive and when it sets I forgive ->
http://moj.skavt.net/gleskovs/
Always in Heart, Grega Leskovšek
--- End Message ---
--- Begin Message ---
I think it's not the best place to send it but:
$dolgF is not closed with ; ...and the insert is not in a variable!
(And also I think it's not a good way using COOKIE in PHP because we have
sessions....)
So the answer is: the all.. :D -or what's the full part you use for insert
int this source!?
On Mon, May 16, 2011 at 5:11 PM, Grega Leskovšek <[email protected]> wrote:
> $ime=$_COOKIE['user'];
> $dolgF=filesize($filename)
> INSERT INTO `friendlyCMS`.`log` (`imepriimek`, `clock`, `action`,
> `onfile`, `filesize`) VALUES ( $ime, CURRENT_TIMESTAMP,
> 'saved',$filename, $dolgF);
>
> What is wrong with this?
> PS First column of the log table is idlog primary key autoincrement
> not null - I suppose I omit this when adding to table?
> Thanks in advance, Grega
> -- When the sun rises I receive and when it sets I forgive ->
> http://moj.skavt.net/gleskovs/
> Always in Heart, Grega Leskovšek
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Hi All,
I'm scratching my head a bit here. I have a form handling script that
branches dependent on whether a user has admin privileges over the
application. Here's the function that tests this:
function isAdmin($user){
global $chan;
$query = "SELECT isadmin FROM csw_user WHERE username = '" .
mysql_real_escape_string($user) . "'";
// echo "<p>$query</p>\n";
$result_table = mysql_query ($query, $chan) or die ("Error: Can't retrieve
the data");
if ($result_row = mysql_fetch_array ($result_table)){
$canAdminister = $result_row['isadmin'] > 0;
} else {
$canAdminister = FALSE;
}
return ($canAdminister);
}
Note the commented echoing of the query, which I uncommented during
debugging.
This function was failing with the message from die() "Error: Can't
retrieve the data". On uncommenting the echo statement, I got:
SELECT isadmin FROM csw_user WHERE username = ''
IOW, there was a blank string passed to the isAdmin function.
So I checked at a higher level and temporarily modified the code to
read:
echo "<pre>";
print_r ($_COOKIE);
echo "</pre>\n";
$canAdministrate = isAdmin($_COOKIE['username']);
This showed that $_COOKIE['username'] contained the username of the
logged-on user as I expected, yet that username was not passed to the
isAdmin function 8-/
FWIW, I've resolved the issue in that it no longer happens. I'd
forgotten to put the opening and closing html, head, and body tags and
the issue went away as soon as I did that. However, I'd appreciate
info on why as I need to run some scripts within a validated user
session where those scripts do their processing and then use the
header function to redirect the browser to an appropriate page.
TIA,
--
Geoff
--- End Message ---
--- Begin Message ---
On Sun, May 15, 2011 at 3:15 PM, Richard Quadling <[email protected]>wrote:
> Personally, I would recommend using 1 naming convention and sticking with
> it.
>
I wholeheartedly agree. Multiple method names is not flexibility--it's
confusion and an open invitation for bugs. Plus, even with two styles you'll
never satisfy everyone. For example I would expect getNumRows() or
getRowCount().
David
--- End Message ---
--- Begin Message ---
You can register a shutdown function that gets called even in the case of a
fatal error. We use something like this:
public function init() {
register_shutdown_function(array('Bootstrap', 'fatalErrorCatcher'));
...
}
public function fatalErrorCatcher() {
$error = error_get_last();
if( $error && (
$error['type'] === E_ERROR ||
$error['type'] === E_COMPILE_ERROR ||
$error['type'] === E_CORE_ERROR ||
$error['type'] === E_PARSE
)) {
// kill the buffer content, it's broken anyway
while(ob_get_level()) {
ob_end_clean();
}
// log error to a file
...
// issue 500 and dump out a static "site is broken oh noes!"
page
header('HTTP/1.1 500 Internal Server Error');
echo file_get_contents('fail-whale.html');
}
}
In catchFatalError() we check the last error to see if it's truly fatal. Our
general error-handler has already handled all other error types, and this
since function gets called no matter how the PHP process shutsdown, you
don't want to issue a 500 for a successful request. :)
David
--- End Message ---
--- Begin Message ---
On 14 May 2011 at 15:05, Peter Lind <[email protected]> wrote:
> On 14 May 2011 12:33, Tim Streater <[email protected]> wrote:
>> I would like, in my app, to recover from as many run-time errors as possible,
>> so that I can tidy up. And unsolicited output generated by the standard error
>> system is really unhelpful as it becomes part of the ajax reply to the
>> browser.
>>
>> So I've added my own error handler, but it seems that I can't catch fatal
>> errors. The error in question comes from doing something like:
>
> Fatal errors are fatal - if you could recover from them, they wouldn't be
> fatal.
Except that this error is arbitrarily designated as fatal when it need not be.
A few days ago I discovered register_shutdown_function as mentioned by someone
today, and use that to pass E_ERRORs on to my error handler (as declared by
set_error_handler). That way I can log the error properly and notify the user
in a consistent manner. I've tested this by introducing some errors (e.g.
unitialised variables or setting $dbh to null) and these are all nicely picked
up.
>> $res = $dbh->query ($sql);
>>
>> with $sql being an SQL statement, and $dbh being a database handle. I
>> recently had a case where $dbh was NULL, which triggers a fatal error from
>> SQLite. In principle such a bug should show up quickly, but this one had lain
>> untriggered for about a year. It seems to me somewhat arbitrary for this to
>> be designated a fatal error. Is there a way I can catch these? Most SQLite
>> error situations I'm solving with try/catch but no luck with this one so far.
>
> You've got something wrong: either $dbh is not null or the error is
> not from sqlite. I'm guessing the former. To avoid situations like
> that, do proper error checking (i.e. actually check that your database
> connection was opened succesfully).
No, $dbh was unitialised. It was a coding error where I was using $dbhs instead
of $dbh. Since what I was apparently trying to do last year was wrong anyway
I've rejigged that section. And obviously I do check that the db is opened;
just that in this instance I was using the wrong variable.
>> Error handling in library packages seems somewhat arbitrary - e.g. opendir
>> may give an E_WARNING, but closedir, readdir don't.
>
> You can avoid all problems with error output by turning off error
> displays in php.ini (set display_errors = off) - use error logging
> instead. That's the recommended setting for production servers.
This is not a browser/webserver situation in the classic manner. In this case,
the browser, PHP code, and the instance of apache used are all running on the
user's machine. The user just thinks they are running a local application.
Cheers -- tim
--- End Message ---
--- Begin Message ---
On 16 May 2011 22:14, Tim Streater <[email protected]> wrote:
> On 14 May 2011 at 15:05, Peter Lind <[email protected]> wrote:
>
>> On 14 May 2011 12:33, Tim Streater <[email protected]> wrote:
>>> I would like, in my app, to recover from as many run-time errors as
>>> possible,
>>> so that I can tidy up. And unsolicited output generated by the standard
>>> error
>>> system is really unhelpful as it becomes part of the ajax reply to the
>>> browser.
>>>
>>> So I've added my own error handler, but it seems that I can't catch fatal
>>> errors. The error in question comes from doing something like:
>>
>> Fatal errors are fatal - if you could recover from them, they wouldn't be
>> fatal.
>
> Except that this error is arbitrarily designated as fatal when it need not
> be. A few days ago I discovered register_shutdown_function as mentioned by
> someone today, and use that to pass E_ERRORs on to my error handler (as
> declared by set_error_handler). That way I can log the error properly and
> notify the user in a consistent manner. I've tested this by introducing some
> errors (e.g. unitialised variables or setting $dbh to null) and these are all
> nicely picked up.
You were trying to call a method on a non-object - how do you expect
PHP to handle that if not with a fatal error?
Anyway, good to hear you solved the issue - I misunderstood what you
wanted to do (shut down in a proper fashion, not actually recover from
the error) so I didn't think to mention this.
* snip *
>> You can avoid all problems with error output by turning off error
>> displays in php.ini (set display_errors = off) - use error logging
>> instead. That's the recommended setting for production servers.
>
> This is not a browser/webserver situation in the classic manner. In this
> case, the browser, PHP code, and the instance of apache used are all running
> on the user's machine. The user just thinks they are running a local
> application.
You can call it production server or not, if you are having problems
with error messages from php then you should turn off error display -
which shouldn't get in the way of you showing your own error messages
but will solve the problem mentioned.
Regards
Peter
--
<hype>
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
</hype>
--- End Message ---
--- Begin Message ---
On 16 May 2011 at 21:34, Peter Lind <[email protected]> wrote:
> You were trying to call a method on a non-object - how do you expect
> PHP to handle that if not with a fatal error?
> Anyway, good to hear you solved the issue - I misunderstood what you
> wanted to do (shut down in a proper fashion, not actually recover from
> the error) so I didn't think to mention this.
Thanks, yes, that all appears to be function OK now. Meanwhile I'm chasing a
strangeness to do perhaps with UTF-8 - I send some simplified Chinese back from
the PHP side as part of an ajax response to the browser for it to display, and
in one case it does it right, in another the browser converts it to something
else. I'm trying to duplicate this in a testbed with no success so far. Still,
it keeps me off the streets :-)
Cheers -- tim
--- End Message ---
