InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comFri, 24 May 2013 12:29:54 GMT20http://www.sqlservercentral.com/Forums/Topic364313-7-1.aspxHi,I faced the same issue , on analysing I found that Article setting for "if the object with same name already exists" was to "Truncate table and reload data" . I modified it to "Delete the object and re-create" then it worked fine.Solution :Modified Article properties for the table Property : Action if name in use Earlier Value : Truncate All data in the existing objectFixed value : Drop Existing object and create a new oneRegards,AviThu, 17 May 2012 07:53:12 GMTJas-365681http://www.sqlservercentral.com/Forums/Topic364313-7-1.aspxUnfortunately I've changed contract since this posting so can't check what the settings are now on the database. From what I recall I turned off all the replication of objects so that only the data was being transferred. Sorry can't help any further.Mon, 21 Apr 2008 04:10:25 GMTBrian Jones-401554http://www.sqlservercentral.com/Forums/Topic364313-7-1.aspxThanks for the response.I already have auto create and auto update statistics off on the destination database. my source is sql 2000 and my destination is sql 2005. Do you have any idea?ThanksFri, 18 Apr 2008 13:12:25 GMTAmeena Lalani-347953http://www.sqlservercentral.com/Forums/Topic364313-7-1.aspxTurning off the auto-statistics on the destination database worked for me, and performance is fine for my needs. So not pursued this any further.Fri, 18 Apr 2008 12:06:23 GMTBrian Jones-401554http://www.sqlservercentral.com/Forums/Topic364313-7-1.aspxHi,I am having the same problem. I have transactional replication from 2000 to 2005. Were you able to resolve your problem? Can you post your experience here.Thanks a lot.Thu, 17 Apr 2008 11:33:27 GMTAmeena Lalani-347953http://www.sqlservercentral.com/Forums/Topic364313-7-1.aspx<P>No it's definitely a transactional replication publication.</P><P>I will turn off the auto create stats - still a little confused though. The statistic was a weird name (hind_133213 or something) which I don't think is an auto stat, and the same name existed on both databases. There is no index or column called hind, and chances of it being the same name should be pretty slim. I think it was replicated across and an untrapped error occurred, which left the replication in disarray.</P><P>What is more concerning is that there were empty tables in the database. I have the articles set to delete data from tables on the snapshot page, and I assumed that this only occurred (deletion from table) when a snapshot was produced (i.e. on reinitialisation). This seems to indicate that a snapshot was performed, but I have no idea why that should have occurred. I assumed that with a transactional replication only the new/edited/deleted rows were replicated, not the whole of the table after each change.</P><P>Anyhow, have turned off the auto create stats and will see what happens. I am interested as to what impact that will have, the 2005 database is for reporting only, so I would expect it to have different statistics from the 2000 database (which is the data entry database) as the data is used in a different way.</P>Wed, 09 May 2007 08:00:00 GMTBrian Jones-401554http://www.sqlservercentral.com/Forums/Topic364313-7-1.aspx<P>I would double check the article and see if doesn't mention Merge replication as that is the only one I know you can drop that setting.</P><P>However that said check that the database you are replicating to does not have auto create statistics turned on for the database. I would think that should correct the issue.</P>Wed, 09 May 2007 07:36:00 GMTAntares686http://www.sqlservercentral.com/Forums/Topic364313-7-1.aspx<P>I have straight forward transactional replication set up on a SQL2000 database to a SQL 2005 database. The distribution agent is on SQL2000 and is push replication.</P><P>Recently the replication has failed with the error "There are already statistics on table" error number 1927. When this occurs I have data missing from other tables aswell which is very strange. </P><P>The error is correct, and to cure it I have to remove the offending statistic on 2005 and reinitialise the replication. What is also strange is that the statistic name is not _WA but another name (and not the name of an index). Obviously this is not the ideal situation as firstly this could occur at any time and therefore leave the database unusable (and some angry users as this is a 24/7 application), and secondly a reinitialisation of the replication could take some time.</P><P>I have found an article in the MS Knowledge Base, however it does not work. The reason it does not work is because it suggests turning off the "Copy objects to destination...Non clustered indexes" option in the article. However this option is disabled and I can not change it.</P><P>Does anyone have any insight into this error, I need a direction to investigate desparately.</P><P>Thanks,</P><P>Brian Jones</P>Wed, 09 May 2007 04:41:00 GMTBrian Jones-401554