Merge Replication Problem (Private,Public Data - Security Issue)

Hello,
We plan to establish a merge replication topology in which several servers
(subscribers) have "public" data – data that have to be propagated to the
other servers, and private data - data reside only at original servers.
Private and public data are marked with one table column (1/0). Those servers
are at local branches in different countries. We have one server on the
Internet, which can be publisher and hold all public data, besides its own
private data. Subscriptions will be anonymous pull subscriptions. Subscribers
would periodicaly make dialup connections and merge data. Article filter
would be something like "Public=1". The problem is that subscribers' private
data will go to the publisher in merge replication. As far as we understand,
filter is only checked at the publisher and not at the subscriber. Only
public data goes from publisher to the subscribers, but all data goes from
subscriber to the publisher.
Our client is to happy about the fact that data marked as private is
available on the Internet server.
Is there any possibility to prevent private data going to the publisher?
Many thanks in advance.
Mirza
The easiest solution is to partition the data - have 2 tables, one for
private and one for public. This way, the data is protected and can be
selectively replicated. To show the data to the user on teh subscriber you
could use partitioned views, or standard views with an instead-of trigger.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Merge replication ExchangeType question.

I have an application that will have very limited functionality in a
disconnected mode. I plan on recording operations in the one area of our
application where we allow inserts in disconnected mode and updating the
publisher through custom code that basically replays what the user did in
disconnected mode. Then using merge replication in dowload only mode to pull
any updates back to the subscriber.
My question is do I need to delete the rows that were inserted in
disconnected mode on the subscriber before starting the merge process. I am
concerned that the publisher will see the inserts from the custom code and
attempt an insert on the subscriber even though the row already exists there.
Is merge replication smart enough (in download only mode) to delete the rows
that were added in disconnected mode on the subscriber (since they don't
exist on the publisher) before inserting the rows from the publisher? To put
it another way, does merge replication try to completely synchronize data on
both the subscriber and the publisher by forcing the subscriber to have the
same data as the publisher in download only mode?
I think my last post may have been confusing.
Can the data be modified or inserted on the subscriber but then the
subscriber be forced to synchronize completely with the publisher's copy of
the database. In other words, any data created on the subscriber is purged
during the merge process instead inserted into the publisher?
|||I'd have to test, but I think you'll have to remove these rows yourself. You
can identify them by matching the guids in msmerge_contents, and this could
be an extra step in the merge agent's job.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Yes, you will need to delete the rows on the subscriber, otherwise you will
get a conflict when the row moves from the publisher to the subscriber.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"mspradley" <mspradley@.discussions.microsoft.com> wrote in message
news:8F9DE6A4-B8F1-45D3-843C-4EA6F5F6BF94@.microsoft.com...
> I have an application that will have very limited functionality in a
> disconnected mode. I plan on recording operations in the one area of our
> application where we allow inserts in disconnected mode and updating the
> publisher through custom code that basically replays what the user did in
> disconnected mode. Then using merge replication in dowload only mode to
pull
> any updates back to the subscriber.
> My question is do I need to delete the rows that were inserted in
> disconnected mode on the subscriber before starting the merge process. I
am
> concerned that the publisher will see the inserts from the custom code and
> attempt an insert on the subscriber even though the row already exists
there.
> Is merge replication smart enough (in download only mode) to delete the
rows
> that were added in disconnected mode on the subscriber (since they don't
> exist on the publisher) before inserting the rows from the publisher? To
put
> it another way, does merge replication try to completely synchronize data
on
> both the subscriber and the publisher by forcing the subscriber to have
the
> same data as the publisher in download only mode?