php-general Digest 24 Sep 2009 05:05:57 -0000 Issue 6355
Topics (messages 298289 through 298306):
Re: NULLS vs Empty result in PHP
298289 by: Bastien Koert
Re: How to take output from an include, and embed it into a variable?
298290 by: Ben Dunlap
298292 by: Jim Lucas
Re: Extract links from strings
298291 by: Jim Lucas
Stricter Error Checking?
298293 by: Tim Legg
298294 by: Jonathan Tapicer
298295 by: Tommy Pham
298296 by: Jonathan Tapicer
298297 by: Bob McConnell
298298 by: Tommy Pham
298299 by: Shawn McKenzie
298300 by: Shawn McKenzie
298301 by: Shawn McKenzie
298302 by: Jim Lucas
298306 by: Samrat Kar
Re: session.gc_maxlifetime
298303 by: Tom Worster
298304 by: Ralph Deffke
Re: User Account Management
298305 by: Waynn Lue
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 ---
On Wed, Sep 23, 2009 at 11:35 AM, Philip Thompson
<[email protected]> wrote:
> On Sep 23, 2009, at 9:48 AM, Dan Shirah wrote:
>
>>>
>>> From reading the other responses to this thread, it seems that you want
>>> to
>>> "skip" or "exclude" rows in the results where my_column === null.
>>>
>>> If this is correct, why not do it in the SELECT statement to begin with?
>>>
>>> $my_query = "SELECT my_column FROM my_database WHERE my_column IS NOT
>>> NULL";
>>>
>>> That should do it.
>>>
>>
>> I want to exclude the rows that might be NULL, "" (empty), or " "
>> (empty series of spaces)
>>
>> From all of the input so far, it seems that using trim() on the variable
>> and
>> then use empty() is the best way to pick all three types up.
>
> I don't think you're using mysql, but your selected db may have a similar
> option. I would do the work in the sql.
>
> <?php
> $sql = "SELECT * FROM `table` WHERE TRIM(`column`) <> '' AND `column` IS NOT
> NULL";
> $result = query($sql);
> while ($row = fetch_row ($result)) {
> echo "Not empty, multiple spaces or NULL!";
> }
> ?>
>
> So, if you have any extraneous spaces, they will be removed. It also
> accounts for nulls. No work is required by PHP to determine the values you
> need. Just use what it returns. This should work.
>
> Hope this helps.
> ~Philip
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Another thought might be to convert the nulls into another value
select field1, field2, ISNULL(field3,'-') from table where ...
would convert the nulls into hyphens
--
Bastien
Cat, the other other white meat
--- End Message ---
--- Begin Message ---
> $file = 'invoicetable_bottom.php';
> fopen("http://yoursite.com/folder/$file","r";);
>
> http://tr.php.net/function.fopen
>
> worth trying. Easier than output buffering
Easier in what sense? It would end up requiring more code than
output-buffering because you'd have to read from the file after
calling fopen(), check for end-of-file, etc., and it seems needlessly
inefficient because it:
- uses a function, fopen(), instead of a language construct, include()
- generates a superfluous HTTP request
I think it's also counter-intuitive. I ran across a similar technique
in some code I was reviewing and I had to really scratch my head and
wonder why the original author of the code did that, instead of just
getting at the file via the local file system.
Finally, it would require the OP to store an include()-ed file inside
of DocumentRoot -- which I personally prefer not to do when I can
avoid it (although that approach is debatable).
Ben
--- End Message ---
--- Begin Message ---
Ashley Sheridan wrote:
> On Wed, 2009-09-23 at 07:36 -0700, Jim Lucas wrote:
>> Mert Oztekin wrote:
>>> Output buffering will do it.
>>>
>>> Also I am not sure but did you try retrieving content with fopen() ?
>>>
>>> Something like
>>>
>>> $file = 'invoicetable_bottom.php';
>>> fopen("http://yoursite.com/folder/$file","r";);
>>>
>>> http://tr.php.net/function.fopen
>>>
>>> worth trying. Easier than output buffering
>>>
>> This would not work. fopen would open the file for read. What you would be
>> reading is the actual source of the document. Not the data the script would
>> output when ran.
>>
>> The ob_* functions are the only way that I know of to do what you are asking
>>
>>> -----Original Message-----
>>> From: Puiu Hrenciuc [mailto:[email protected]]
>>> Sent: Wednesday, September 23, 2009 1:36 PM
>>> To: [email protected]
>>> Subject: [PHP] Re: How to take output from an include, and embed it into a
>>> variable?
>>>
>>> Hi,
>>>
>>> The simplest way (actually the single way I know :) ) would be to
>>> capture the output using output buffering functions, something like this:
>>>
>>> // start output buffering
>>> ob_start();
>>>
>>> // include the file that generates the HTML (or whatever content)
>>> include "....";
>>>
>>> // get output buffer content
>>> $output=ob_get_contents();
>>>
>>> // clean output buffer and stop buffering
>>> ob_end_clean();
>>>
>>> // the content generated in the included file is now in $output variable
>>> // use it as you consider fit
>>> .........
>>>
>>>
>>> Regards,
>>> Puiu
>>>
>>>
>>> Rob Gould wrote:
>>>> I have an invoice table that is drawn on a number of pages, so I have
>>>> all the logic in an include-file like this:
>>>>
>>>> include "invoicetable_bottom.php";
>>>>
>>>>
>>>> However, now I'm needing to take the output from that include file and
>>>> pass it as an email. To do that, I need to somehow take the output from
>>>> this include file and get it into a variable somehow. Is there a simple
>>>> way to do this?
>>>>
>>>> Something like: $emailtcontent = include "invoicetable_bottom.php"?
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
> That's just crazy talk. If you use fopen on a web URL, then it will
> always return the output the script generates. That's how http works!
>
Sorry, my bad. Ash is correct, the method that is suggested will work. But you
will need to enable options in your php.ini that are not on by default for
security reasons, plus as Ben points out, you will need to filter out the scruff
that is generated to capture just the data output from your include.
Mind you that all of this also requires that the file that you are including is
accessible via the web. It could be in a folder that is not web accessible.
Sorry for the initial confusion!
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
--- End Message ---
--- Begin Message ---
Philip Thompson wrote:
> On Sep 21, 2009, at 6:20 PM, Jim Lucas wrote:
>
>> Jim Lucas wrote:
>>> Jônatas Zechim wrote:
>>>> Hi there, i've the following strings:
>>>>
>>>> $string1 = 'Lorem ipsum dolor http://site.com sit amet';
>>>> $string2 = 'Lorem ipsum dolor http://www.site.com/ sit amet';
>>>> $string3 = 'Lorem ipsum dolor http://www.site.net sit amet';
>>>>
>>>> How can I extract the URL from these strings?
>>>> They can be [http:// + url] or [www. + url].
>>>>
>>>> Zechim
>>>>
>>>>
>>>
>>> Something like this should work for you.
>>>
>>> <plaintext><?php
>>>
>>> $urls[] = 'Lorem ipsum dolor http://site.com sit amet';
>>> $urls[] = 'Lorem ipsum dolor https://www.site.com/ sit amet';
>>> $urls[] = 'Lorem ipsum dolor www.site1.net sit amet';
>>> $urls[] = 'Lorem ipsum dolor www site2.net sit amet';
>>>
>>> foreach ( $urls AS $url ) {
>>> if ( preg_match('%((https?://|www\.)[^\s]+)%', $url, $m) ) {
>>> print_r($m);
>>> }
>>> }
>>>
>>> ?>
>>>
>>
>> Actually, try this. It seems to work a little better.
>>
>> <plaintext><?php
>>
>> $urls[] = 'Lorem ipsum dolor http://site.com sit amet';
>> $urls[] = 'Lorem ipsum dolor https://www.site.com/ or
>> http://www.site2.com/';
>> $urls[] = 'Lorem ipsum dolor www.site1.net sit amet';
>> $urls[] = 'Lorem ipsum dolor www site2.net sit amet';
>>
>> foreach ( $urls AS $url ) {
>> if ( preg_match_all( '%(https?://[^\s]+|www\.[^\s]+)%',
>> $url,
>> $m,
>> (PREG_SET_ORDER ^ PREG_OFFSET_CAPTURE)
>> ) ) {
>> print_r($m);
>> }
>> }
>>
>> ?>
>
> What if the sub domain was not 'www'?
>
> http://no-www.org/
>
Well, if it had the http:// at the beginning, then it would be found.
but, somedomain.no-www.org would not work.
But, if they only had no-www.org, it would only find www.org
So, I guess it would need to be looking at the characters before the www\. part
to include them in the url also
This should work. Note: the [^\s]+ placed before the www\. portion.
if ( preg_match_all( '%(https?://[^\s]+|[^\/\s]+www\.[^\s]+)%',
This should catch example.www.org and no-www.org now.
You could get into the business of trying to match the TLD, but that would be a
PITA to keep updated.
> Cheers,
> ~Philip
>
>
--- End Message ---
--- Begin Message ---
Hello,
I just spent way, way to much time trying to debug code due to a misnamed
element. Here is a simplified example of the problem I dealt with.
$test = "SELECT * FROM `Materials` WHERE `Part_Number` = '125664'";
$result = mysql_query($test,$handle);
if(!$result)
{
die('Error: ' . mysql_error());
}
$row = mysql_fetch_array($result);
echo $row['Number'];
After retyping the code 3 or 4 times over the course of the morning, I finally
found where the problem was. The problem is that the database field is called
'Part_Number', not 'Number'. The field 'Number' does not exist in the
database. I am very surprised that I didn't even get a warning that there
might be a problem with the statement. All I saw is that nothing was being
returned via the echo command.
There really must be a stricter error checking that is turned on somewhere,
isn't there?
Thanks for your help.
Tim
--- End Message ---
--- Begin Message ---
Hi,
There is, see here (or it can also be set through php.ini):
http://www.php.net/manual/en/function.error-reporting.php
You are looking for E_STRICT.
Regards,
Jonathan
On Wed, Sep 23, 2009 at 3:11 PM, Tim Legg <[email protected]> wrote:
> Hello,
>
> I just spent way, way to much time trying to debug code due to a misnamed
> element. Here is a simplified example of the problem I dealt with.
>
>
> $test = "SELECT * FROM `Materials` WHERE `Part_Number` = '125664'";
> $result = mysql_query($test,$handle);
> if(!$result)
> {
> die('Error: ' . mysql_error());
> }
> $row = mysql_fetch_array($result);
> echo $row['Number'];
>
> After retyping the code 3 or 4 times over the course of the morning, I
> finally found where the problem was. The problem is that the database field
> is called 'Part_Number', not 'Number'. The field 'Number' does not exist in
> the database. I am very surprised that I didn't even get a warning that
> there might be a problem with the statement. All I saw is that nothing was
> being returned via the echo command.
>
> There really must be a stricter error checking that is turned on somewhere,
> isn't there?
>
>
> Thanks for your help.
>
> Tim
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
----- Original Message ----
> From: Tim Legg <[email protected]>
> To: [email protected]
> Sent: Wednesday, September 23, 2009 11:11:46 AM
> Subject: [PHP] Stricter Error Checking?
>
> Hello,
>
> I just spent way, way to much time trying to debug code due to a misnamed
> element. Here is a simplified example of the problem I dealt with.
>
>
> $test = "SELECT * FROM `Materials` WHERE `Part_Number` = '125664'";
> $result = mysql_query($test,$handle);
> if(!$result)
> {
> die('Error: ' . mysql_error());
> }
> $row = mysql_fetch_array($result);
> echo $row['Number'];
>
> After retyping the code 3 or 4 times over the course of the morning, I
> finally
> found where the problem was. The problem is that the database field is
> called
> 'Part_Number', not 'Number'. The field 'Number' does not exist in the
> database. I am very surprised that I didn't even get a warning that there
> might
> be a problem with the statement. All I saw is that nothing was being
> returned
> via the echo command.
if(!$result)
{
die('Error: ' . mysql_error());
}
This didn't work when you used 'Number' instead of 'Part_Number'? Strange...
>
> There really must be a stricter error checking that is turned on somewhere,
> isn't there?
>
>
> Thanks for your help.
>
> Tim
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
I think he meant that he is using 'Number' instead of 'Part_Number'
when accessing the array and not in the SQL, his SQL was correct, this
was wrong:
> echo $row['Number'];
E_STRICT catches that kind of error.
Jonathan
On Wed, Sep 23, 2009 at 3:28 PM, Tommy Pham <[email protected]> wrote:
>
>
> ----- Original Message ----
>> From: Tim Legg <[email protected]>
>> To: [email protected]
>> Sent: Wednesday, September 23, 2009 11:11:46 AM
>> Subject: [PHP] Stricter Error Checking?
>>
>> Hello,
>>
>> I just spent way, way to much time trying to debug code due to a misnamed
>> element. Here is a simplified example of the problem I dealt with.
>>
>>
>> $test = "SELECT * FROM `Materials` WHERE `Part_Number` = '125664'";
>> $result = mysql_query($test,$handle);
>> if(!$result)
>> {
>> die('Error: ' . mysql_error());
>> }
>> $row = mysql_fetch_array($result);
>> echo $row['Number'];
>>
>> After retyping the code 3 or 4 times over the course of the morning, I
>> finally
>> found where the problem was. The problem is that the database field is
>> called
>> 'Part_Number', not 'Number'. The field 'Number' does not exist in the
>> database. I am very surprised that I didn't even get a warning that there
>> might
>> be a problem with the statement. All I saw is that nothing was being
>> returned
>> via the echo command.
>
> if(!$result)
> {
> die('Error: ' . mysql_error());
> }
>
> This didn't work when you used 'Number' instead of 'Part_Number'? Strange...
>
>>
>> There really must be a stricter error checking that is turned on somewhere,
>> isn't there?
>>
>>
>> Thanks for your help.
>>
>> Tim
>>
>>
>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
From: Tommy Pham
>> From: Tim Legg
>>
>> I just spent way, way to much time trying to debug code due to a
misnamed
>> element. Here is a simplified example of the problem I dealt with.
>>
>>
>> $test = "SELECT * FROM `Materials` WHERE `Part_Number` =
'125664'";
>> $result = mysql_query($test,$handle);
>> if(!$result)
>> {
>> die('Error: ' . mysql_error());
>> }
>> $row = mysql_fetch_array($result);
>> echo $row['Number'];
>>
>> After retyping the code 3 or 4 times over the course of the morning,
I finally
>> found where the problem was. The problem is that the database field
is called
>> 'Part_Number', not 'Number'. The field 'Number' does not exist in
the
>> database. I am very surprised that I didn't even get a warning that
there might
>> be a problem with the statement. All I saw is that nothing was being
returned
>> via the echo command.
>
> if(!$result)
> {
> die('Error: ' . mysql_error());
> }
>
> This didn't work when you used 'Number' instead of 'Part_Number'?
Strange...
>
I think the problem is that he didn't check that the key he used
actually existed before using the value it pointed to. So he got an
empty string for $row['Number']; because the key should have been
'Part_Number'. I don't know that even E_STRICT would catch that one.
Bob McConnell
--- End Message ---
--- Begin Message ---
----- Original Message ----
> From: Bob McConnell <[email protected]>
> To: Tommy Pham <[email protected]>; [email protected]
> Sent: Wednesday, September 23, 2009 11:37:00 AM
> Subject: RE: [PHP] Stricter Error Checking?
>
> From: Tommy Pham
> >> From: Tim Legg
> >>
> >> I just spent way, way to much time trying to debug code due to a
> misnamed
> >> element. Here is a simplified example of the problem I dealt with.
> >>
> >>
> >> $test = "SELECT * FROM `Materials` WHERE `Part_Number` =
> '125664'";
> >> $result = mysql_query($test,$handle);
> >> if(!$result)
> >> {
> >> die('Error: ' . mysql_error());
> >> }
> >> $row = mysql_fetch_array($result);
> >> echo $row['Number'];
> >>
> >> After retyping the code 3 or 4 times over the course of the morning,
> I finally
> >> found where the problem was. The problem is that the database field
> is called
> >> 'Part_Number', not 'Number'. The field 'Number' does not exist in
> the
> >> database. I am very surprised that I didn't even get a warning that
> there might
> >> be a problem with the statement. All I saw is that nothing was being
> returned
> >> via the echo command.
> >
> > if(!$result)
> > {
> > die('Error: ' . mysql_error());
> > }
> >
> > This didn't work when you used 'Number' instead of 'Part_Number'?
> Strange...
> >
>
> I think the problem is that he didn't check that the key he used
> actually existed before using the value it pointed to. So he got an
> empty string for $row['Number']; because the key should have been
> 'Part_Number'. I don't know that even E_STRICT would catch that one.
>
> Bob McConnell
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
My mistake, didn't have enough caffeine for the day :)
--- End Message ---
--- Begin Message ---
>> I think the problem is that he didn't check that the key he used
>> actually existed before using the value it pointed to. So he got an
>> empty string for $row['Number']; because the key should have been
>> 'Part_Number'. I don't know that even E_STRICT would catch that one.
>>
>> Bob McConnell
>
> What? With E_ALL or E_STRICT:
>
> Notice: Undefined index: Number in file.php on line X
>
My bad, E_ALL only.
--- End Message ---
--- Begin Message ---
Bob McConnell wrote:
> From: Tommy Pham
>>> From: Tim Legg
>>>
>>> I just spent way, way to much time trying to debug code due to a
> misnamed
>>> element. Here is a simplified example of the problem I dealt with.
>>>
>>>
>>> $test = "SELECT * FROM `Materials` WHERE `Part_Number` =
> '125664'";
>>> $result = mysql_query($test,$handle);
>>> if(!$result)
>>> {
>>> die('Error: ' . mysql_error());
>>> }
>>> $row = mysql_fetch_array($result);
>>> echo $row['Number'];
>>>
>>> After retyping the code 3 or 4 times over the course of the morning,
> I finally
>>> found where the problem was. The problem is that the database field
> is called
>>> 'Part_Number', not 'Number'. The field 'Number' does not exist in
> the
>>> database. I am very surprised that I didn't even get a warning that
> there might
>>> be a problem with the statement. All I saw is that nothing was being
> returned
>>> via the echo command.
>> if(!$result)
>> {
>> die('Error: ' . mysql_error());
>> }
>>
>> This didn't work when you used 'Number' instead of 'Part_Number'?
> Strange...
>
> I think the problem is that he didn't check that the key he used
> actually existed before using the value it pointed to. So he got an
> empty string for $row['Number']; because the key should have been
> 'Part_Number'. I don't know that even E_STRICT would catch that one.
>
> Bob McConnell
What? With E_ALL or E_STRICT:
Notice: Undefined index: Number in file.php on line X
--
Thanks!
-Shawn
http://www.spidean.com
--- End Message ---
--- Begin Message ---
Tim Legg wrote:
> Hello,
>
> I just spent way, way to much time trying to debug code due to a misnamed
> element. Here is a simplified example of the problem I dealt with.
>
>
> $test = "SELECT * FROM `Materials` WHERE `Part_Number` = '125664'";
> $result = mysql_query($test,$handle);
> if(!$result)
> {
> die('Error: ' . mysql_error());
> }
> $row = mysql_fetch_array($result);
> echo $row['Number'];
>
> After retyping the code 3 or 4 times over the course of the morning, I
> finally found where the problem was. The problem is that the database field
> is called 'Part_Number', not 'Number'. The field 'Number' does not exist in
> the database. I am very surprised that I didn't even get a warning that
> there might be a problem with the statement. All I saw is that nothing was
> being returned via the echo command.
>
> There really must be a stricter error checking that is turned on somewhere,
> isn't there?
>
>
> Thanks for your help.
>
> Tim
>
>
>
When developing you should always use something like this:
ini_set('display_errors', 'On');
error_reporting(E_ALL);
--
Thanks!
-Shawn
http://www.spidean.com
--- End Message ---
--- Begin Message ---
Tim Legg wrote:
> Hello,
>
> I just spent way, way to much time trying to debug code due to a misnamed
> element. Here is a simplified example of the problem I dealt with.
>
>
> $test = "SELECT * FROM `Materials` WHERE `Part_Number` = '125664'";
> $result = mysql_query($test,$handle);
> if(!$result)
> {
> die('Error: ' . mysql_error());
> }
> $row = mysql_fetch_array($result);
> echo $row['Number'];
>
> After retyping the code 3 or 4 times over the course of the morning, I
> finally found where the problem was. The problem is that the database field
> is called 'Part_Number', not 'Number'. The field 'Number' does not exist in
> the database. I am very surprised that I didn't even get a warning that
> there might be a problem with the statement. All I saw is that nothing was
> being returned via the echo command.
>
> There really must be a stricter error checking that is turned on somewhere,
> isn't there?
>
>
> Thanks for your help.
>
> Tim
>
>
>
>
This would generate a E_NOTICE level "warning"
to see the errors of you ways you would need the following at the top of your
script, or set in your php.ini file or in a .htaccess file.
In script example:
<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);
...
?>
.htaccess & php.ini example:
error_reporting = E_ALL
display_errors = On
The default setting in PHP
error_reporting = E_ALL & ~E_NOTICE
display_errors = On
--- End Message ---
--- Begin Message ---
Better use mysqli rather mysql. It supports all new features of MySQL.
I solved the problem in following manner.
1. Detect the return value of mysqli->query function.
2. If it is FALSE get the error no, error msg etc and store in a Mysql table
for further review. You can also write it in a error log file.
Example...
/* Part of MYSQLI class */
public function Query($sql, $flag = 0) {
$my = new mysqli($this->host,$this->user,$this->pass,$this->db);
if(mysqli_connect_errno()) {
$this->conn_err_no = mysqli_connect_errno();
$this->conn_err_msg = mysqli_connect_error();
return FALSE;
}
//$this->QueryLog(addslashes($sql));
$arr1 = explode(" ", $sql);
$queryType = $arr1[0];
$result = $my->query($sql);
if($result === FALSE) {
$this->query_err_no = $my->errno;
$this->query_err_msg = $my->error;
$this->sqlstate = $my->sqlstate;
$this->ErrorLog(addslashes($sql));
}
else {
$this->QueryLog(addslashes($sql));
}
if($queryType == "SELECT" || $queryType == "SHOW" || $queryType ==
"DESCRIBE" || $queryType == "EXPLAIN" || $queryType == "CALL") {
if($result) {
$num_row = $result->num_rows;
$num_col = $result->field_count;
if($num_row == 0)
$ret = NULL;
if($num_row == 1 && $num_col == 1) {
$record = $result->fetch_row();
if($flag == 1)
$ret = array($record[0]);
else
$ret = $record[0];
}
if($num_row == 1 && $num_col > 1) {
if($flag == 1)
$ret = array($result->fetch_array());
else
$ret = $result->fetch_row();
}
if($num_row > 1 && $num_col == 1) {
$retarr = array();
while($record = $result->fetch_array()) {
array_push($retarr, $record[0]);
}
$ret = $retarr;
}
if($num_row > 1 && $num_col > 1) {
$retarr = array();
while($record = $result->fetch_array()) {
array_push($retarr, $record);
}
$ret = $retarr;
}
if($num_row > 0) {
$this->field_list = $result->fetch_fields();
}
}
else {
return FALSE;
}
}
else {
if($result === FALSE)
return FALSE;
if($queryType == "UPDATE" || $queryType == "INSERT" ||
$queryType == "REPLACE" || $queryType == "DELETE") {
$ret = $my->affected_rows;
if($queryType == "INSERT")
$this->last_insert_id = $my->insert_id;
}
}
return $ret;
}
private function QueryLog($query) {
$my = new mysqli($this->host,$this->user,$this->pass,$this->db);
if(mysqli_connect_errno()) {
$this->conn_err_no = mysqli_connect_errno();
$this->conn_err_msg = mysqli_connect_error();
return FALSE;
}
$ts = time();
$sql = "INSERT INTO pi_global.tblquerylog
VALUES('','$ts','$query')";
$my->query($sql);
$my->close();
}
private function ErrorLog($query) {
$my = new mysqli($this->host,$this->user,$this->pass,$this->db);
if(mysqli_connect_errno()) {
$this->conn_err_no = mysqli_connect_errno();
$this->conn_err_msg = mysqli_connect_error();
return FALSE;
}
$ts = time();
$errno = $this->query_err_no;
$errmsg = addslashes($this->query_err_msg);
$state = $this->sqlstate;
$sql = "INSERT INTO pi_global.tblerrorlog
VALUES('','$ts','$query','$errno','$errmsg','$state')";
$my->query($sql);
$my->close();
}
Regards,
Samrat Kar
FRD, BARC
Tel: 022-25597295
Alternate Email: [email protected]
-----Original Message-----
From: Tim Legg [mailto:[email protected]]
Sent: Wednesday, September 23, 2009 11:42 PM
To: [email protected]
Subject: [PHP] Stricter Error Checking?
Hello,
I just spent way, way to much time trying to debug code due to a misnamed
element. Here is a simplified example of the problem I dealt with.
$test = "SELECT * FROM `Materials` WHERE `Part_Number` = '125664'";
$result = mysql_query($test,$handle);
if(!$result)
{
die('Error: ' . mysql_error());
}
$row = mysql_fetch_array($result);
echo $row['Number'];
After retyping the code 3 or 4 times over the course of the morning, I
finally found where the problem was. The problem is that the database field
is called 'Part_Number', not 'Number'. The field 'Number' does not exist in
the database. I am very surprised that I didn't even get a warning that
there might be a problem with the statement. All I saw is that nothing was
being returned via the echo command.
There really must be a stricter error checking that is turned on somewhere,
isn't there?
Thanks for your help.
Tim
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.112/2391 - Release Date: 09/23/09
18:00:00
--- End Message ---
--- Begin Message ---
there's a need for long timeouts in this app but could perhaps be reduced
from 6 to 3 hours.
the sessions are cookie based using php's 'file' handler and
session.cookie_lifetime=0. the server appears to have plenty of free memory
and appears not to have swapped in nearly a year of uptime. load averages
indicate a pretty quiet server. there are currently 170 kbyte total in 90
serialized session files which is typical and not a memory load. the
distribution of modification times doesn't indicate heavy activity: ~20
files in the last 15 minutes and 35 in the last hour.
so i think the os can handle this. plus the app ran for 6 years before
anyone reported being prematurely logged off. i'm looking for other
possibilities: odd browser behavior, network trouble, ...
are there any browsers that have configurable cookie handling policy such
that they time out a cookie?
one web site i use displays this curious message: "For your protection,
sessions are open for a limited period of time on our website. Please
sign-on again. NOTE: Your browser may also limit secure connection time, and
automatically log you out independent of our timeout procedure."
that could be referring to browsers timing out an ssl connection. or perhaps
the cookie?
btw: when you said in your email you wouldn't trust a long gc_maxlifetime,
and you would only use a cookie-based solution for long session. did you
mean that you wouldn't trust php's cookie-based session handler? and you
would use a custom handler instead?
On 9/22/09 4:46 PM, "Ralph Deffke" <[email protected]> wrote:
> Hi Tom,
>
> in sometimes 2001 I did have incidences with those things, and as I remember
> over the past years there where some trouble with operating systems and
> stuff. This part is very deep inside the os. I would expect that this is
> still to consider. I also would check, if this occurs on very busy/low
> memory server.
>
> If I would programm the garbage collection clean up part, and if the server
> is about to run out of memory, I would kill sessions being longer time idle
> even when they are not yet as old as it is set in the gc_maxlifetime. This
> would be far better then shutting down the whole server just because there a
> 100 of idle sessions waiting to get used again.
>
> as u mention a maxlivetime of 6h I would bet, that this is the problem. I
> would not trust such a long lifetime at all.
>
> If sessions have to be active such a long time, I would see only cooky based
> solutions
>
> let me know, what u did investigate on this.
>
> [email protected]
>
>
> "Tom Worster" <[email protected]> wrote in message
> news:c6deae55.12cae%[email protected]...
>> thank you, Ralph!
>>
>> i'm going to be bold and assume that tom at punkave dot com is right
> despite
>> that the report was discarded.
>>
>> i got a complaint from a client about some users reporting being logged
> out
>> with rather short periods of inactivity. but session.gc_maxlifetime is set
>> to 6 hours so i don't think that's the source of the problem.
>>
>>
>> On 9/22/09 4:17 PM, "Ralph Deffke" <[email protected]> wrote:
>>
>>> Hi Tom,
>>>
>>> i did find this in the bug reports, its pretty new and should be an
> answer.
>>>
>>> http://news.php.net/php.doc.bugs/2653
>>>
>>> [email protected]
>>>
>>>
>>> "Tom Worster" <[email protected]> wrote in message
>>> news:c6de9eee.12c8d%[email protected]...
>>>> i'm not 100% sure what the manual means when it says...
>>>>
>>>> session.gc_maxlifetime integer
>>>> session.gc_maxlifetime specifies the number of seconds after which data
>>> will
>>>> be seen as 'garbage' and cleaned up. Garbage collection occurs during
>>>> session start.
>>>>
>>>> what event exactly does the "after which" here refer to?
>>>>
>>>> i'd like to think that it means that a session is eligible for gc no
>>> sooner
>>>> than session.gc_maxlifetime seconds after the most recent access (read
> or
>>>> write) to that session. but it seems dangerously presumptuous to assume
>>> that
>>>> this is the case.
>>>>
>>>> what do you take it to mean?
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--- End Message ---
--- Begin Message ---
finaly we went with a custom cooky handling, however the customers
requirements where two days.
if u are shure that the server is still the same hardware like it has been 6
years ago then it might be some client stuff, however if there are other
applications, pages running (virtual servers) then it would still be to
consider. mamory and resource management is deep os. again I wouldn't trust
for that amount of session livetime.
I dont think, putting it down to three hours would help much.
and of course, it could be client side also. Can't you figure out the
clients?
and keep in mind that a lot of people connect to UMTS rigzt now, these
systems deconnect on idle lines and reconect without the users even know it.
Also a lot of lines change IP address at midnihgt.
cheers
[email protected]
"Tom Worster" <[email protected]> wrote in message
news:c6e00521.12d98%[email protected]...
> there's a need for long timeouts in this app but could perhaps be reduced
> from 6 to 3 hours.
>
> the sessions are cookie based using php's 'file' handler and
> session.cookie_lifetime=0. the server appears to have plenty of free
memory
> and appears not to have swapped in nearly a year of uptime. load averages
> indicate a pretty quiet server. there are currently 170 kbyte total in 90
> serialized session files which is typical and not a memory load. the
> distribution of modification times doesn't indicate heavy activity: ~20
> files in the last 15 minutes and 35 in the last hour.
>
> so i think the os can handle this. plus the app ran for 6 years before
> anyone reported being prematurely logged off. i'm looking for other
> possibilities: odd browser behavior, network trouble, ...
>
>
> are there any browsers that have configurable cookie handling policy such
> that they time out a cookie?
>
> one web site i use displays this curious message: "For your protection,
> sessions are open for a limited period of time on our website. Please
> sign-on again. NOTE: Your browser may also limit secure connection time,
and
> automatically log you out independent of our timeout procedure."
>
> that could be referring to browsers timing out an ssl connection. or
perhaps
> the cookie?
>
>
> btw: when you said in your email you wouldn't trust a long gc_maxlifetime,
> and you would only use a cookie-based solution for long session. did you
> mean that you wouldn't trust php's cookie-based session handler? and you
> would use a custom handler instead?
>
>
> On 9/22/09 4:46 PM, "Ralph Deffke" <[email protected]> wrote:
>
> > Hi Tom,
> >
> > in sometimes 2001 I did have incidences with those things, and as I
remember
> > over the past years there where some trouble with operating systems and
> > stuff. This part is very deep inside the os. I would expect that this is
> > still to consider. I also would check, if this occurs on very busy/low
> > memory server.
> >
> > If I would programm the garbage collection clean up part, and if the
server
> > is about to run out of memory, I would kill sessions being longer time
idle
> > even when they are not yet as old as it is set in the gc_maxlifetime.
This
> > would be far better then shutting down the whole server just because
there a
> > 100 of idle sessions waiting to get used again.
> >
> > as u mention a maxlivetime of 6h I would bet, that this is the problem.
I
> > would not trust such a long lifetime at all.
> >
> > If sessions have to be active such a long time, I would see only cooky
based
> > solutions
> >
> > let me know, what u did investigate on this.
> >
> > [email protected]
> >
> >
> > "Tom Worster" <[email protected]> wrote in message
> > news:c6deae55.12cae%[email protected]...
> >> thank you, Ralph!
> >>
> >> i'm going to be bold and assume that tom at punkave dot com is right
> > despite
> >> that the report was discarded.
> >>
> >> i got a complaint from a client about some users reporting being logged
> > out
> >> with rather short periods of inactivity. but session.gc_maxlifetime is
set
> >> to 6 hours so i don't think that's the source of the problem.
> >>
> >>
> >> On 9/22/09 4:17 PM, "Ralph Deffke" <[email protected]> wrote:
> >>
> >>> Hi Tom,
> >>>
> >>> i did find this in the bug reports, its pretty new and should be an
> > answer.
> >>>
> >>> http://news.php.net/php.doc.bugs/2653
> >>>
> >>> [email protected]
> >>>
> >>>
> >>> "Tom Worster" <[email protected]> wrote in message
> >>> news:c6de9eee.12c8d%[email protected]...
> >>>> i'm not 100% sure what the manual means when it says...
> >>>>
> >>>> session.gc_maxlifetime integer
> >>>> session.gc_maxlifetime specifies the number of seconds after which
data
> >>> will
> >>>> be seen as 'garbage' and cleaned up. Garbage collection occurs during
> >>>> session start.
> >>>>
> >>>> what event exactly does the "after which" here refer to?
> >>>>
> >>>> i'd like to think that it means that a session is eligible for gc no
> >>> sooner
> >>>> than session.gc_maxlifetime seconds after the most recent access
(read
> > or
> >>>> write) to that session. but it seems dangerously presumptuous to
assume
> >>> that
> >>>> this is the case.
> >>>>
> >>>> what do you take it to mean?
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>
--- End Message ---
--- Begin Message ---
Thanks so much for all the feedback! Ben's comment was something that
prompted this discussion to begin with internally, in that we didn't want to
reinvent the wheel, nor make a mistake in the security implenetation of our
solution. I've forwarded this thread back internally, and we'll take this
as a jumping off point for how to build our system.
Waynn
--- End Message ---
