Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
DB Engine
SQL ServerMSDESQL Server CE
Services
Analysis (Data Mining)Analysis (OLAP)DTSIntegration ServicesNotification ServicesReporting Services
Programming
CLRConnectivitySQLXML
Other Technologies
ClusteringEnglish QueryFull-Text SearchReplicationService Broker
General
Data WarehousingPerformanceSecuritySetupSQL Server ToolsOther SQL Server Topics
DirectoryUser Groups
Related Topics
MS AccessOther DB ProductsMS Server Products.NET DevelopmentVB DevelopmentJava DevelopmentMore Topics ...

SQL Server Forum / Other Technologies / Replication / January 2006

Tip: Looking for answers? Try searching our database.

Deletes occurring at publisher

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
marshallae@bowater.com - 30 Jan 2006 16:01 GMT
I'm using Merge replication on a table with an autoidentity field.  All
users are entering data at the publisher (no records are ever deleted),
and at the subscribers the data is read-only.  I'm having a problem
with records being deleted at the publisher.  I'm assuming it has to do
with a subscriber having problems, but I can't track it down.

Moving forward (SQL 2005), I want to change the replication type to
transactional.  Could someone please tell me the best type of
replication to use in order to prevent records from being deleted at
the publisher?

Any help would be greatly appreciated.

Thanks,

Amy Marshall
Hilary Cotter - 30 Jan 2006 16:50 GMT
Does anything show up in the conflict viewer? The deletes could be logged
here. Are you using join filters? These can cause these types of deletes,
but normally not on the publisher.

Transactional replication is designed for one way replication. It is not
clear to me what your data flow requirements are. With transactional
replication users will be able to delete data in any location, but only
deletes occurring on the publisher will be replicated to the subscriber.

Signature

Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html

Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com

> I'm using Merge replication on a table with an autoidentity field.  All
> users are entering data at the publisher (no records are ever deleted),
[quoted text clipped - 12 lines]
>
> Amy Marshall
marshallae@bowater.com - 30 Jan 2006 19:37 GMT
This morning I had 264 conflicts, which I kept to make sure I got the
deleted records back into the table, but this was the first time there
were any conflicts at all for that table. We are not using any join
filters on this table.  I was thinking of using transactional
replication, because all entries into the problem table are done at the
publisher, and the inputs into that table are synched to the
subscribers based on a timeframe that is set from an application which
determines sync times. (Most users set synch times anywhere from 60
minutes - 240 minutes).

What's weird, is that there is a table that is in the same merge
package, that links to an ID in the problem table, but those records
are NEVER deleted at the publisher (no foreign key constraint exists
between the 2 tables).  This one table seems to have the problem, and
while monitoring replication, I rarely ever see problems with
subscribers and this package.

Thanks for your input.

Amy
Paul Ibison - 30 Jan 2006 17:15 GMT
Amy,
the issue might be caused by compensating changes. Please take a look at :
http://support.microsoft.com/default.aspx?scid=kb;en-us;828637&Product=sql2k
 Cheers,
       Paul Ibison SQL Server MVP, www.replicationanswers.com
         (recommended sql server 2000 replication book:
         http://www.nwsu.com/0974973602p.html)
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.