How to query for records that have not been replicated

[miltonmoura]

Hi,

I am using Merge Replication for synchronizing a bunch of laptops
running MSDE with a central SQL Server 2000 production server.

This database is used by an application that needs to know which
records have not yet been replicated, at any givem time.

Here's a simple scenario:

User A in laptop X starts his copy of the application. He syncs his
MSDE database through the application, to match the current central
servers' data. He then proceeds to add new records through the
application and, after he is done, he synchronizes his database with
the central server, through the application.

At any given time, the user might kill the application. He might add
some records today, a few more tomorrow or in a week and should be able
to change and delete records that have not yet been merged into the
production server.

The problem is that SQL Server does not have an easy way to tell which
records in the subscription tables have been inserted but not yet
replicated. I have been using the following query:

SELECT rowguid
FROM [MyTable]
INNER JOIN (
SELECT rowguid AS rep_id
FROM msmerge_contents
WHERE generation = joinchangegen AND generation = (
SELECT MAX(generation)
FROM msmerge_genhistory )
) dtable
ON rowguid_rep = dtable.rep_id

This query works for most cases but fails to identify the first record
created immediatly after a synchronization event.

What I would like to know is if there is a correct way of identifying
records which are "not-yet-replicated" on a given table that is part of
a merge replication process like the one described above.
Thanks in advance.

[Simon Hayes]

<mi*********@gmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

Hi,

I am using Merge Replication for synchronizing a bunch of laptops
running MSDE with a central SQL Server 2000 production server.
<snip>
What I would like to know is if there is a correct way of identifying
records which are "not-yet-replicated" on a given table that is part of
a merge replication process like the one described above.
Thanks in advance.

I have no idea myself, but you might get a better response in
microsoft.public.sqlserver.replication.

Simon