On Thursday 19 July 2007 00:03:19 Roderick A. Anderson wrote:
> I'll post my solution ... when I figure one out!
You could, in the script from cron:
1 - check for the presence of rows in a 'alive_scripts_table'
if any , then exit, and go for the next run,
alternativly, check that pid in 'ps -ef
Alan Hodgson wrote:
On Wednesday 18 July 2007 14:29, "Roderick A. Anderson" <[EMAIL PROTECTED]>
wrote:
In the mean time if the script gets triggered again and the first
instance isn't finished the second needs to not be able to select those
records already being handled.
select for update won'
On Wednesday 18 July 2007 14:29, "Roderick A. Anderson" <[EMAIL PROTECTED]>
wrote:
> In the mean time if the script gets triggered again and the first
> instance isn't finished the second needs to not be able to select those
> records already being handled.
select for update won't do that. It wil
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Will a $sth->execute()
of a "SELECT ... FOR UPDATE" statement allow me to update the selected
records using
$uth->execute( ... )
if $sth and $uth are both created/prepared from the same database handle
"$dbh"?
You
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>Will a $sth->execute()
> of a "SELECT ... FOR UPDATE" statement allow me to update the selected
> records using
> $uth->execute( ... )
> if $sth and $uth are both created/prepared from the same database handle
> "$dbh"?
You are allowed to upda
Hopefully the original post went astray and this isn't a duplicate. I
don't see it in the archive so I'll assume I have a bogus SMTP setup at
work for my home account.
I've tried the Pg docs, DBI book, and Google searches but haven't found
anything useful on this topic.
I realize this is mor
