Should I use Data Replication to perform this task??

Question

Should I use Data Replication to perform this task??

Viewing 6 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply

Troy Cross-310336 Grasshopper Points: 12 More actions · Answer 1

I used a replicated view once in a similiar situation.

basically set up a view on your database that has the same name as the table on the ms erp database, the view would point to a table with similiar structure but possibly not the same.

other way is to set up identical table on your database and then use triggers on your database to write the data in some other form.

Steve-3_5_7_9 SSChampion Points: 10832 More actions · Answer 2

Similiar to previous post.

The MS ERP database writes the data into a clone of the "SaleOrder" table. This can be done via a trigger. This "SalesOrder" table is then replicated.

Ian Woods SSC Enthusiast Points: 115 More actions · Answer 3

Thanks for your help on this one.

I know you are asking yourself why not do a lookup on the ERP database tables when needed, well one of the spec's required was that if the ERP database was taken offline my warehouse application (database) could still pick the sales order's.

Ok, so I write the triggers to clone the ERP Database table(s). Any pointers as to how I setup the replication on the cloned table(s)?

Thanks once more..

Dinakar Nethi-176633 SSCarpal Tunnel Points: 4689 More actions · Answer 4

since the tables have different structures I doubt if replication will work. You could dig into the sp_MSinsert/update/delete stored proc generated by the replication wizard and mess with them but replication itself is messy enough and again having to deal with this is prbly not worth it. I would recommend triggers if that is an option. Some companies have rules -NO Triggers (ours does).

******************
Dinakar Nethi
Life is short. Enjoy it.
******************

Carolyn Richardson SSCrazy Eights Points: 8357 More actions · Answer 5

Personally I would create an interim table, on your subscriber server, identical to the source table, you can replicate the source data into this new table, you can then use say a stored proc that fires either by a trigger on this table or as a timed event to populate the required table. In this way you can isolate any data errors prior to import. This gives you more control of the data into your table.

Regards

Carolyn

Facts are stubborn things, but statistics are more pliable - Mark Twain
Carolyn
SQLServerSpecialists[/url]

Ian Woods SSC Enthusiast Points: 115 More actions · Answer 6

Thanks for your post Carolyn,

I will give your solution a go, you are right it does give me more control over the data needed.

Regards Ian