This is a fairly common approach in Unix environments. A file is saved under the /var/run/ directory with the contents being the PID of the process that started it. Deamons check for the file common to itself and die if they see the file there (though it sounds like you want to sleep instead).

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

Another thought would be to put a flag in your database that a waking process would check to see if there was another process already running.

Just as an aside, I once wrote an application similar to what you are describing where the client invoked CGI program did not directly update the database. Instead the updates were put into a staging table along with information telling another script who placed the updates there in the queue and another periodically run script did the actual updates. Additionally the client scripts would send a signal to the daemon that most of the time was ignored except when the daemon was "sleeping"

Now you are on XP so I don't know how this concept would port to your environment. If the concept of a service from NT made it over then your daemon would be a service.

Another scheme would be to write the updates to a spool directory and let your service pick up the updates from there and process them accordingly.

Another thought would be to put a flag in your database that a waking process would check to see if there was another process already running.

That's a good thought. I implemented it five minutes, flat. This actually set my mind off on a tangent, and I created a DB-table to hold parameters for the program, as well, so that I can also track the most common invocations. Needed to make minor changes to the code (e.g. get parameters from DB via DBI instead from command-line), but it was smooth. Thanks for a great idea.