Can I use profiler to watch a table from an application?

I need to create an application which watches for changes to one or two
tables in a SQL Server database.
I originally considered adding a trigger to the table which would add a row
to another table recording some information about the change. This second
table would then be scanned by the application (it would delete rows it had
processed - in fact it would be a queue).
However I was wondering if I could instead create a trace which the
application could monitor in real time. It seems that traces can be created
which are written to a file, but you have to stop the trace to look at the
file.
Any suggestions?
Are you watching for changes to the table or to the data? If you are
watching for data changes why not just add a column (or two or three) along
the lines of
Created datetime
Updated datetime
Processed datetime
When data is insert or updated the corresponding column can be set with the
current date. The application that would monitor the table could use these
columns along with the Processed column to determine if it needs to do
anything.
Keith
"Graham Morris" <Graywing@.newsgroup.nospam> wrote in message
news:%234sjY0yzFHA.612@.TK2MSFTNGP10.phx.gbl...
>I need to create an application which watches for changes to one or two
>tables in a SQL Server database.
> I originally considered adding a trigger to the table which would add a
> row to another table recording some information about the change. This
> second table would then be scanned by the application (it would delete
> rows it had processed - in fact it would be a queue).
> However I was wondering if I could instead create a trace which the
> application could monitor in real time. It seems that traces can be
> created which are written to a file, but you have to stop the trace to
> look at the file.
> Any suggestions?
>
|||I want to detect changes to the data. I am trying to minimise the impact on
the database schema - creating new columns in the table is completely out
I'm afraid, but I can get away with adding triggers.
I was hoping that if I can tap in to a profiler trace, I can watch for
changes to the table. It seems though that I can't do this programmatically
the way the profiler interface does.
"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
news:e1ACFJzzFHA.1252@.TK2MSFTNGP09.phx.gbl...
> Are you watching for changes to the table or to the data? If you are
> watching for data changes why not just add a column (or two or three)
> along the lines of
> Created datetime
> Updated datetime
> Processed datetime
> When data is insert or updated the corresponding column can be set with
> the current date. The application that would monitor the table could use
> these columns along with the Processed column to determine if it needs to
> do anything.
> --
> Keith
>
> "Graham Morris" <Graywing@.newsgroup.nospam> wrote in message
> news:%234sjY0yzFHA.612@.TK2MSFTNGP10.phx.gbl...
>
|||How do your applications insert and update data?
If they insert/update multiple rows within one statement you will have to
code your trigger in such a way as to handle that.
If the applications insert and update data via stored procedures you could
just add a second insert (or update) statement to the stored procedure so
that the appropriate data would be added to your log table.
I would stay away from the profiler trace idea. This is more for monitoring
than for firing off events.
Keith
"Graham Morris" <Graywing@.newsgroup.nospam> wrote in message
news:%23tjrpF0zFHA.3720@.TK2MSFTNGP14.phx.gbl...
>I want to detect changes to the data. I am trying to minimise the impact
>on the database schema - creating new columns in the table is completely
>out I'm afraid, but I can get away with adding triggers.
> I was hoping that if I can tap in to a profiler trace, I can watch for
> changes to the table. It seems though that I can't do this
> programmatically the way the profiler interface does.
> "Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
> news:e1ACFJzzFHA.1252@.TK2MSFTNGP09.phx.gbl...
>
|||OK, I'll forget the profiler idea
"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
news:OUznc70zFHA.3408@.TK2MSFTNGP09.phx.gbl...
> How do your applications insert and update data?
> If they insert/update multiple rows within one statement you will have to
> code your trigger in such a way as to handle that.
> If the applications insert and update data via stored procedures you could
> just add a second insert (or update) statement to the stored procedure so
> that the appropriate data would be added to your log table.
> I would stay away from the profiler trace idea. This is more for
> monitoring than for firing off events.
> --
> Keith
>
> "Graham Morris" <Graywing@.newsgroup.nospam> wrote in message
> news:%23tjrpF0zFHA.3720@.TK2MSFTNGP14.phx.gbl...
>