Replication Error 21395 Column ID >255

  • During publisher's creation, I got the following:

    SQL Server could not create article 'MASTER_DIST' (name of

    my table) based on object 'MASTER_DIST'.

    Do you want to continue saving other changes to the

    publication?

    Error 21395: This column can not be included in a

    transactional publication because the column ID is greater

    than 255.

    The column was not added correctly to the article.

    Please help!

    .

  • Two questions.

    1) What version of SQL and SP level are you running?

    2) How many columns does the biggest table involved in replication have.

    "Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)

  • 1) SQL Server 2000 with SP1.

    2) At first I had 1 table with 270 columns and I got error 20068. I broke the table into 2 tables (240 and 31 with the right index of course so I can create a view later) and got a 21395. My problem I believe resides in the syscolumns table where the COLID values remain the same even after I deleted the columns in the first table. The COLID column appeared to be out of sequence. Going from say 1-110, it skipped 111-142 and continued again from 143-270. Can I use Enterprise Manager to put everything back to sequential order like 1-240? Would this corrupt the database? Thanks in advance.

  • That i what I was thinking. First I would make a backup of the database, as always for safety, and try one of these at a time things.

    Try installing SP2 to see if clears, if not then try next.

    Check out my article at

    quote:


    http://www.sqlservercentral.com/columnists/jtravis/changingcolumn.asp


    which was the same kind of problem when using a linked server from SQL 7 to 2000. At the bottom I posted a script that updates and corrects the values into a sequential fashion. Note however there was a post that at least one person who tried it had there data become erratic, so I do suggest test after you are sure your data is backedup, and preferrably do on a test machine first. If this does not work then restore your DB or if you wan to avoid and have the space.

    Create a new table with a different name but all same structure. Copy the data from the original table into the new table. Make scripts of or documentation of any triggers, constraints and defaults on the original table that have not been applied to the new table. Delete the old table, rename the new table the old name and apply back the items I stated previously. This means a new table, fully organized will be built and should not be an issue.

    "Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)

Viewing 4 posts - 1 through 3 (of 3 total)

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