php-general Digest 26 Jul 2006 09:33:24 -0000 Issue 4259
Topics (messages 239779 through 239786):
Re: xml v php question
239779 by: Jim Moseby
Re: Lots of queries!
239780 by: Jochem Maas
239782 by: Philip Thompson
mail headers
239781 by: Schalk
239785 by: Chris
Re: SQL Result Set -> HTML Table Fragment (but Simple)
239783 by: tedd
Efficiency question
239784 by: Paul Scott
Re: Stumped! 4.x to 5.1 problem!!
239786 by: Jochem Maas
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 Tue, July 25, 2006 3:15 pm, Kevin Waterson said:
> > This one time, at band camp, Larry Garfield <[EMAIL PROTECTED]>
> > wrote:
> >
> >> The correct answer is (b). (PHP 6 won't even have short
> tags, so get
> >> used to
> >> not having them.)
> >
> > ummm, I think it was decided to stay in php6. I could be
> mildly/wildly
> > mistaken
> >
> > Kevin
>
> The last I heard, they were still slated for removal. The
> PHP core team
> does have a habit of changing their minds about such things
> on a regular
> basis, however, so who knows what their plan is this week. :-)
>
What the PHP core team does or doesn't do has no bearing on the fact that
short tags are bad voodoo. Just say no to short tags, and your life will be
easier, your shirts whiter, and your teeth brighter!
JM <-- who has never used short tags, and never will
--- End Message ---
--- Begin Message ---
Philip Thompson wrote:
> Hi all.
>
> I have a list of people in a database who live in particular rooms. Next
lucky them, back when I was a kid you were lucky if you had a cardboard box,
and a wet one at that.... ok let's not go down that road ;-)
> semester, they may live somewhere else, so I need to update my database.
> (I know the data becomes stale, but not that often.) Here's what I'm
> doing to update:
>
> 1. Pull list of IDs from database A - store in array
> 2. Foreach ID in array, search database B to see if they have a new room
> 2a. If no, go back to step 2 and go to next ID
> 3. Compare new room to current room
> 3a. If different, update the record to new room
>
> That's basically it. Now, I know this works (sorta) because the records
> are updating with the appropriate information. Here's the problem I'm
> running into: it only does a certain amount and then quits!! WHY!!?!
your script is timing out. search this lists archive, the web and the manual
for more info.
AND THEN ... assuming your script is not fundamentally flawed (i.e there is not
a way
you could do what you want much faster and with *way* less queries) ...
go make your update script to work as a cmdline script (so it works from the
cmdline
rather than being called from the browser);
basically it sounds like what you want to do could more suitably considered
as 'offline' processing - something you shouldn't be triggering from a http
request.
(cmdline scripts don't timeout by default, where as scripts run via http do -
you can force scripts run via http to keep going but if you need to do that
there is
something wrong - any script run via web request should finish in a few seconds
at most)
>
> The total number of records I have is 1335 - pulled from step 1.
> However, when I go through the list and query for new rooms, it stops...
> randomly... not even at the same record each time. Sometime it's 230,
> sometimes it's 476 - truly random from what I can tell. I am sorting the
> query (ORDER BY) each time, so I know it's the same order.
>
> Any thoughts on why this is happening? Possibly a buffer issue?
>
> Thanks in advance.
> ~Philip
>
> --PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
Well, we figured out. Jochem, thanks for your input... a few minutes
too late! =D We discovered that it *was* timing out at 30 seconds,
which is how it was set in the php.ini file. We upped that and now it
works.
THANKS!!
~Philip
On Jul 25, 2006, at 3:34 PM, Jochem Maas wrote:
Philip Thompson wrote:
Hi all.
I have a list of people in a database who live in particular
rooms. Next
lucky them, back when I was a kid you were lucky if you had a
cardboard box,
and a wet one at that.... ok let's not go down that road ;-)
semester, they may live somewhere else, so I need to update my
database.
(I know the data becomes stale, but not that often.) Here's what I'm
doing to update:
1. Pull list of IDs from database A - store in array
2. Foreach ID in array, search database B to see if they have a
new room
2a. If no, go back to step 2 and go to next ID
3. Compare new room to current room
3a. If different, update the record to new room
That's basically it. Now, I know this works (sorta) because the
records
are updating with the appropriate information. Here's the problem I'm
running into: it only does a certain amount and then quits!! WHY!!?!
your script is timing out. search this lists archive, the web and
the manual
for more info.
AND THEN ... assuming your script is not fundamentally flawed (i.e
there is not a way
you could do what you want much faster and with *way* less
queries) ...
go make your update script to work as a cmdline script (so it works
from the cmdline
rather than being called from the browser);
basically it sounds like what you want to do could more suitably
considered
as 'offline' processing - something you shouldn't be triggering
from a http request.
(cmdline scripts don't timeout by default, where as scripts run via
http do -
you can force scripts run via http to keep going but if you need to
do that there is
something wrong - any script run via web request should finish in a
few seconds at most)
The total number of records I have is 1335 - pulled from step 1.
However, when I go through the list and query for new rooms, it
stops...
randomly... not even at the same record each time. Sometime it's 230,
sometimes it's 476 - truly random from what I can tell. I am
sorting the
query (ORDER BY) each time, so I know it's the same order.
Any thoughts on why this is happening? Possibly a buffer issue?
Thanks in advance.
~Philip
--- End Message ---
--- Begin Message ---
Greetings Everyone,
What in the piece of code below might be causing the headers for from
and reply-to to be set incorrectly?
'
$headers = "MIME-Version: 1.0\r\n".
"Content-type: text/html; charset=iso-8859-1\r\n".
"From: ".$email."\r\n".
"Reply-to: ".$email."\r\n".
"Date: ".date("r")."\r\n";
'
Using Thunderbird on XP it does set the from correctly but then uses the
default from address set in php.ini for the reply-to. Any ideas? Thanks!
--
Kind Regards
Schalk Neethling
Web Developer.Designer.Programmer.President
Volume4.Business.Solution.Developers
--- End Message ---
--- Begin Message ---
Schalk wrote:
Greetings Everyone,
What in the piece of code below might be causing the headers for from
and reply-to to be set incorrectly?
'
$headers = "MIME-Version: 1.0\r\n".
"Content-type: text/html; charset=iso-8859-1\r\n".
"From: ".$email."\r\n".
"Reply-to: ".$email."\r\n".
"Date: ".date("r")."\r\n";
'
Using Thunderbird on XP it does set the from correctly but then uses the
default from address set in php.ini for the reply-to. Any ideas? Thanks!
There's a default for reply-to in the php.ini? What's the variable
called - I can't see one. I can see these:
[mail function]
; For Win32 only.
SMTP = localhost
; For Win32 only.
sendmail_from = [EMAIL PROTECTED]
; For Unix only. You may supply arguments as well (default: 'sendmail
-t -i').
;sendmail_path =
but they have nothing to do with the reply-to address.
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
At 10:55 AM -0400 7/25/06, tedd wrote:
At 12:46 AM -0400 7/25/06, Michael B Allen wrote:
Ok, I've been tinkering a little. This isn't "simple" but it's not a
lot of code either.
Granted, and no offense, it isn't simple the way you've attempted it.
You simply have three columns with these conditions:
1. Is gray if odd;
2. Is a time stamp
3. Is green if > 1000.
After placing your data in arrays via the dB, start a table and loop
pulling variables ($i, $timestamp[], $value[]) from the arrays and
display them like so:
<td id="<?php if ($i & 1) echo "grey"; ?>"> <?php echo($i); ?> </td>
<td> <?php echo date("M j, Y g:i a", $timestamp[$i]); ?> </td>
<td id="<?php if ($value[$i]>1000) echo "green"; ?>"> <?php
echo($value[$i]); ?> </td>
Place the colors "gray" and "green" in a css, where they should be.
I have not tested this code, so it may have errors, but the
technique should work.
Just noticed -- slight modification.
The: <td id=" should be: <td class=". The "id" divs can only be used
once per page whereas "class" divs can be used as many times as
needed.
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
I have googled around a bit, but not really found anything useful...
Which is more efficient? A case switch or a $$method style method?
An example:
switch($action) {
case 'edit':
//do some stuff
.......
return "edit_tpl.php";
case 'whatever':
//blah
......
......
}
OR:
$method=$this->convertToMethod($action);
unset($action);
return $this->$method();
Hope this is reasonably clear... Note the return on the latter code.
If anyone has any ideas around this, please let me know! Are there
underlying security risks in doing it this way?
--Paul
All Email originating from UWC is covered by disclaimer
http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm
--- End Message ---
--- Begin Message ---
[email protected] wrote:
>> [email protected] wrote:
>>> [snip]
>>>> seems the perceived problem is being caused by something else?
>>>>
>>> Sorry, I have to respectfully disagree.
>> ok :-).
>
> Men of integrity must be able to disgree peacefully. :-)
>
:-)
>
> Well, the point I was trying to make was that there are other extensions,
> like wddx, that do the same thing, and people should know about it.
extension are version specific so maybe other extension writers/maintainers
have already made the required changes for 5.x version of their work.
you might consider asking the internals mailing list for insight into
the change you perceived, what you *may* have been doing wrong, and/or what
you should be doing to make things works as expected for 5.x.
(I say '*may*' because I have no real knowledge of the engines internals what
so ever)
there are very few people on this list with the requisite engine level
experience/knowledge to help you in a useful way; those that do are more than
likely a to be on the internals list (and more likely to respond to posts made
there)
--- End Message ---
