It is possible, but not easy. If the data is partitioned,
then it is not too difficult, but if not, you'll have to
consider conflicts and how to deal with them.
First of all, you need to know if a row has changed
(inserted or updated), and triggers are the ideal
mechanism for this - yout edit an extra column, or store
the id of the row in a separate table (a separate table
is especially useful for deletes). This has to be done on
the publisher and subscriber. Then routines created to
parse these tables and do joins to find non-matches
before applying the changes. Do you recognise what is
happening as this is worked through? We are essentially
recreating the procedures used by (merge) replication
itself :).
If you have a very simple business requirement, with
partitioned data and no deletes, then it might be worth
looking at the manual solution, otherwise using the
inbuilt tools will save weeks/months of work.
Rgds,
Paul Ibison SQL Server MVP,
www.replicationanswers.com (recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
[quoted text, click to view] >-----Original Message-----
>hi,
>Thanks Paul. But this is not the one i need, I don't
wanna do replication
>by creating publishers and all (Not un\sing the EM). But
i want to know, is
>it possible to do replication manually. i.e .taking the
differfences of the
>tables and inserting it into the curresponding table.
>I think u got it.
>
>regards aneesh
>
>"Paul Ibison" <Paul.Ibison@Pygmalion.Com> wrote in
message
>news:032501c4e1c8$b3ea92e0$a601280a@phx.gbl...
>> I'm not too sure what you mean, but if replication is
set
>> up then the relevant job can be started using
>> sp_start_job. Is this what you were looking for?
>> Rgds,
>> Paul Ibison SQL Server MVP,
www.replicationanswers.com >> (recommended sql server 2000 replication book:
>>
http://www.nwsu.com/0974973602p.html)
>>
>
>
>.
