We have a column that was added to the primary database and is being replicated to a secondary database. We are now receiving the following error:
Column names in each table must be unique. Column name 'RI_SystemType' in table 'dbo.R_Information' is specified more than once. (Source: MSSQLServer, Error number: 2705)
Get help: http://help/2705
Replication is currently failing across the database and we assume that this is the cause. Any suggestions?
Ok, rookie mistake. A deployment script also created the new column in the subscriber. Of course, that's the whole point of replication so once we dropped the column from the subscriber, replication created it itself and all was well.
Related
I am trying to replicate a column with data type char(10) to another column with datatype char(30)
While applying snapshot I get an error saying
"Field Size too large"
As per my understanding Publisher has size smaller than the Subscriber so why would this error come up?
I tried looking over the internet but could not find much help either.
The MSDN forum has pointed a similar issue with a resolution:
I had this same problem. In comparing the schema of the table in both
the publisher and subscriber, they appeared to be identical. However,
I had to drop the table on the subscriber and recreate it using a
create table script generated on the publisher. Once I did that, the
snapshot proceeded without any more errors. HTH.
After adding table to replication it appears in sysmergearticles with status "6" and its not changing after sync, so replication always make drop/create table at subscriber. It started to appear suddenly and i have other tables that works good, but since several days i can't add table to publication without having this issue.
I am seeing this error whilst trying to create an index on a View in SQL Server 2012:
Cannot create index on view "dbo.TestMV" because it references an
internal SQL Server column?
What kind of object is "an internal SQL Server column"?
Such entity is not mentioned in the MS documentation or internet.
P.S. There are no system tables in the view' statement.
Special columns are columns like the undocumented %%physloc%% or %%lockres%% and a couple similar more. They cannot be indexed.
I am using MERGE REPLICATION on my server and now all tables have a rowguid, the last models generated before this change is working very good, but now the new table I imported (using database-first) get the rowguid and making impossible to update, I deleted this column in Model.edmx and I got this error.
Error 3023: Problem in mapping fragments starting at line 551: Column Location.rowguid in table Location must be mapped: It has no default value and is not nullable.
You can backup your database then restore it on another computer without preserving replication settings which will remove all replication traces inclusing the added rowguid columns, then you can generate your entity from the restored database.
I've just come across something disturbing, I was trying to implement transactional replication from a database whose design is not under our control . This replication was in order to perform reporting without taxing the system too much. Upon trying the replication only some of the tables went across.
On investigation tables were not selected to be replicated because they don't have a primary key, I thought this cannot be it is even shown as a primary key if I use ODBC and ms access but not in management studio. Also the queries are not ridiculously slow.
I tried inserting a duplicate record and it failed saying about a unique index(not a primary key). Seems to be the tables have been implemented using a unique index as oppose to a primary key. Why I do not know I could scream.
Is there anyway to perform transactional replication or an alternative, it needs to be live (last minute or two). The main db server is currently sql 2000 sp3a and the reporting server 2005.
The only thing I have currently thought of trying is setting the replication up as if it is another type of database. I believe replication to say oracle is possible would this force the use of say an ODBC driver like I assume access is using hence showing a primary key. I don't know if that is accurate out of my depth on this.
As MSDN states, it is not possible to create a transactional replication on tables without primary keys. You could use Merge replication (one way), that doesn't require a primary key, and it automatically creates a rowguid column if it doesn't exist:
Merge replication uses a globally
unique identifier (GUID) column to
identify each row during the merge
replication process. If a published
table does not have a uniqueidentifier
column with the ROWGUIDCOL property
and a unique index, replication adds
one. Ensure that any SELECT and INSERT
statements that reference published
tables use column lists. If a table is
no longer published and replication
added the column, the column is
removed; if the column already
existed, it is not removed.
Unfortunately, you will have a performance penalty if using merge replication.
If you need to use replication for reporting only, and you don't need the data to be exactly the same as on the publisher, then you could consider snapshot replication also