[dba-SQLServer] Constant Poll: Approaches

Francisco Tapia fhtapia at gmail.com
Fri Jun 13 18:03:31 CDT 2008


I don't see why a trigger would be out of the question.. of course it does
depend on how process intensive the loops will be, but within a trigger you
have the visibility of the new records and can also get a hold of exiting
records.  At this point you can choose to update/append, or even ignore
certain records.

--
Francisco

On Tue, Jun 10, 2008 at 3:40 PM, Stuart McLachlan <stuart at lexacorp.com.pg>
wrote:

> Triggers are probably out of the question because you need to process the
> rows
> sequentially.
>
> Procs with Infinite loops tend to be resource hogs and it's not so easy to
> program complex
> business logic in TSQL.
>
> I'd go with an external agent.
>
> I've got a couple of similar things running.  Both use ODBC for the
> connection and a front
> end application or service which sits in the background and periodically
> polls the data base,
> applies the logic and updates where required.
>
> I generally write this sort of thing in PowerBasic with the SQL Tools ODBC
> package but any
> environment which can generate small footprint executables, can access
> ODBC, can
> "sleep" and can spawn threads will do it.
>
>
>
> On 10 Jun 2008 at 13:27, Arthur Fuller wrote:
>
> > I have a pair of tables, call them Fiction and Fact. People around the
> world
> > enter rows into Fiction. The database has to process these records and
> > depending on some logic, it makes a decision whether or not to enter a
> > similar row into Fact. The logic is not important to my question. What
> I'm
> > trying to do is set up a "polling" system so that the engine will examine
> > the Fiction table every 10 seconds or so and if there are any new rows,
> fire
> > the logic that decides whether to create a row in the Fact table, and
> then
> > timestamp the Fiction row so we know that it's been processed.
> >
> > One important detail in this operation is that I cannot move to row 2
> before
> > completely processing row 1, because the results of row 1 may affect the
> > outcome of row 2.
> >
> > I can think of a couple of approaches -- agent job, trigger, proc with an
> > infinite loop. But before I get started coding this, I thought that I'd
> > reach out and see if anyone's done something similar and has advice on
> which
> > approach might be best.
> >
> > Thanks in advance for any suggestions.
> >
> > Arthur
> > _______________________________________________
> > dba-SQLServer mailing list
> > dba-SQLServer at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> > http://www.databaseadvisors.com
> >
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
-Francisco
http://sqlthis.blogspot.com | Tsql and More...



More information about the dba-SQLServer mailing list