confused about pull

I have setup multiple merge replications that are continuously updating.
Now, we need to have laptops in the field that connect occasionally that
will merge. Because of that, I assume it needs merge PULL subscription.
I have had tons of problems and it has never worked. Right now it seems
to always be a permission issue.
First, I need to test this in the office to make sure it works. If it is
working, can I take that laptop out in the field, connect via the
internet, and it will work there with no changes? This is needed because
90% of the time the user is in the field, but occasionally he is in the
office, and I don't want to have to change configurations when he comes
and goes.
Next, to get a pull setup and functioning in the office, this seems to
require both access to SQL (via a sql login I created) AND access to the
server via a windows login - is this true? If so, what is the windows
login access for (the snapshot I beleive)?
So, I guess in a perfect world the laptop can be first configured and
replicated in the office (to get the snapshot) and then taken out of the
office and connect via the internet.
Does all of this sound reasonable. I know (according to Hilary) this is
a very complex issue and I am discovering it is. Hopefully this is like
a push/merge that seemed complex until it was working, then it was(is)
easy.
Let me know people's thoughts.
Thanks.
Darin
*** Sent via Developersdex http://www.codecomments.com ***
Darin,
the initial Initialization process will require access to the share holding
the snapshot files. This access is by default achieved using the sql server
agent and impersonation. If the account which the agent uses doesn't have
rights to the distributor's working folder (snapshot share) or if the
account is simply not recognised on this server, then there will be
problems. In the case of a non-trusted environment you then have to use an
alternative (usually FTP) to get the initialization going. Once it's going,
the merge agent uses whatever you've set up to do synchronization, over your
configured port. This can be trusted or sql authentication, and by default
it is also trusted.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Conflict resolution for Transactional Replication with Updating Subscribers

Hi.
I'm trying to establish whether Transactional Replication with
Updating Subscribers meets my requirements. I have chosen to use
"publisher wins" for the conflict resolution. (I'm using SqlServer
2005 Developer Edition on Win XP SP2 on both machines)
When I cause a conflict to occur by making an update to rows with the
same PK on both servers, the publisher indicates that there has been a
conflict, and that it chose the publisher as the winner. However, the
losing transaction on the subscriber does not seem to be rolled back
like this article says it should: http://msdn2.microsoft.com/en-us/library/ms151177.aspx.
I'm then left in the state where the two tables are out of sync.
Any ideas anyone?
Cheers!
Some extra info...
I forgot to mention earlier that I'm using a push subscription.
I've found that if I choose 'subscriber-wins' instead, then it seems
to work OK, but unfortunately this is not what I require.
'Normal' changes to data on both servers are correctly replicated to
the other server. It's just publisher-wins conflict resolution that
doesn't seem to work. The conflict is detected, but the publisher's
data is not applied to the subscriber (i.e. the subscriber change is
not rolled back).. Any further changes to that row fail to go through
following the conflict.
Any comments appreciated,
Rich.
On 23 Feb, 08:22, ricisb...@.yahoo.co.uk wrote:
> Hi.
> I'm trying to establish whether Transactional Replication with
> Updating Subscribers meets my requirements. I have chosen to use
> "publisher wins" for the conflict resolution. (I'm using SqlServer
> 2005 Developer Edition on Win XP SP2 on both machines)
> When I cause a conflict to occur by making an update to rows with the
> same PK on both servers, the publisher indicates that there has been a
> conflict, and that it chose the publisher as the winner. However, the
> losing transaction on the subscriber does not seem to be rolled back
> like this article says it should:http://msdn2.microsoft.com/en-us/library/ms151177.aspx.
> I'm then left in the state where the two tables are out of sync.
> Any ideas anyone?
> Cheers!