• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 268
  • Last Modified:

SQL Transactional replication trouble

We have setup a publication of TABLE_INFO on SERVER1 to TABLE_INFO_SERVER1 on a remote subscriber server. This works fine as all entries made at SERVER1 are being replicated to the remote subscriber server destination table of TABLE_INFO_SERVER1 successfully.

When we try adding a second subscription from another server of TABLE_INFO on SERVER2 to TABLE_INFO_SERVER2 the replication initializes correctly, but the SERVER1 table stops updating after initialization.  Then instead of SERVER1 going to its destination table and SERVER2 going to its destination table, all records from both SERVER1 and SERVER2 are now being delivered to the SERVER2 destination tables.

I have checked to ensure that the destination tables at the publisher are configured correctly already. The only thing I can think of is that SQL doesn't like that the name of source tables on both servers are the same. Any assistance is appreciated...
0
MicroAutomation
Asked:
MicroAutomation
  • 6
  • 2
1 Solution
 
MicroAutomationAuthor Commented:
Thanks. Not sure how I chose the wrong zone but definitely needed to be moved.
0
 
venk_rCommented:
Is there any custome stored procedures involved in this replication.
?Is the distribution Server on a separate server and is that being shared by both the subscriptions?
0
 
MicroAutomationAuthor Commented:
No there is no custom stored procedure in use for this.

The Distribution server is a separate server it is being shared by both subscriptions. It is setup to allow each both Publishers to use it. Both publishers are using separate distrib databases. At least as far as I can tell they are.
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
venk_rCommented:
If its more than one distribution database please verify the setup by going thru the below link and make sure they'r setup correctly.The distributor may have been pointing to same destination.

http://www.sqlservercentral.com/articles/Replication/69663/
0
 
MicroAutomationAuthor Commented:
At the distributor we have separated the distribution databases, locations, snapshot folders, etc for each publication. We have read the link and reviewed all the distributor settings.

Same results.
0
 
MicroAutomationAuthor Commented:
Any other thoughts on this?
0
 
MicroAutomationAuthor Commented:
We have started again on this and have setup the initial distributor, publication and subscriber. The tables are being updated in near real-time at the subscriber successfully now. Now just need the other half.

Attached are the setups scripted out for each.

We need to add to this:

Distributor (single server for both publishers)
   - a second allowed publisher on the distributor called abas02 (or IVRNASC01P11)
   - needs to use its own abas02 db and abas02 folder

Publisher (second publishing server)
   - a second publisher with the same publication but everything is abas02 (or IVRNASC01P11)
   - the target tables also change from _as01 to _as02

Subscriber (single subscriber for both publications)
   - add second subscription same as the first but everything is abas02 (or IVRNASC01P11)
   - both publications come to same database on this server only target table names here are different. (_as01 & _as02)


Thanks for any continued assistance...
rep.zip
0
 
MicroAutomationAuthor Commented:
We have corrected the problem on our own. Thanks.
0

Featured Post

Get quick recovery of individual SharePoint items

Free tool – Veeam Explorer for Microsoft SharePoint, enables fast, easy restores of SharePoint sites, documents, libraries and lists — all with no agents to manage and no additional licenses to buy.

  • 6
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now