Any way to obtain changes in tables?

Hi
I'm Using Merge Replication to replicate info from a Pocket PC app. This
info must be integrated with legacy systems in FOXPRO. Is there a way to
obtain changes (new rows and updated rows) in tables to pass it by textfile
to these legacy systems?
For now, i'm experimenting with a status Column in each table. When
inserting or updating in SQLCE i update this column to 0. Once i replicate I
update it to 1(in the pocket). In the server, a memory resident program is
running every two minutes checking for new records (status=0) and exporting
them to a textfile. This, even when functional, i don't think is the best way
to do it. So I ask you if this can be done by a native way in SQL.
Thank you
Regards!
Omar Rojas
It has been a little while since I've used Merge Replication from a CE-based
device, and I'm a little vague on the restrictions but:
Although ugly and possibly undesirable, a trigger on each table to be
tracked could be used to "catch" changes. it could possible update a
"control" table of table name and key values to be processed later by a
formatter that writes the text file, or other, really quick and simple
processing.
You could get trickier and delve into the replication metadata to capture
this information and avoid the triggers, but that requires a relatively
in-depth understanding of the internals of replication.
Cheers.
"Omar Rojas" wrote:

> Hi
> I'm Using Merge Replication to replicate info from a Pocket PC app. This
> info must be integrated with legacy systems in FOXPRO. Is there a way to
> obtain changes (new rows and updated rows) in tables to pass it by textfile
> to these legacy systems?
> For now, i'm experimenting with a status Column in each table. When
> inserting or updating in SQLCE i update this column to 0. Once i replicate I
> update it to 1(in the pocket). In the server, a memory resident program is
> running every two minutes checking for new records (status=0) and exporting
> them to a textfile. This, even when functional, i don't think is the best way
> to do it. So I ask you if this can be done by a native way in SQL.
> Thank you
> Regards!
> Omar Rojas