February 26, 2014 at 2:38 am
Using replication, the published tables can not be altered, so we can't add a field to a table. Why is this?
Is there a way around it?
Is it because the agent is constantly running? If we set the agent to only start up before the Snapshot was taken, would this let us change the tables?
February 26, 2014 at 3:49 am
For a snapshot publication, locks are held on the published tables for the duration of the snapshot generation process so you would not be able to modify the tables during the process, but a more pertinent question is; why are you running the snapshot agent constantly?
Regards
Lempster
February 26, 2014 at 6:49 am
Thanks for the reply.
Its not the snapshot which is running constantly, i think that would be impossible.
When you set the subscription up, theres an option to set the "agent schedule" and this is running constantly. I was wondering if this is causing the issue?
If you click "run on demand only" will this start up when a new snapshot is created?
February 26, 2014 at 7:21 am
So is it the Distribution Agent that is running continuously? Your are definitely using Snapshot Replication and not Transactional Replication, right? How often do you generate a snapshot?
February 26, 2014 at 7:25 am
Yep using snapshot replication. A new Snapshot is created just once a day over night.
February 26, 2014 at 7:59 am
Ok, I think it must be the Distribution Agent that is set to run continuously because i've just gone through setting up Snapshot Replication between a couple of Test databases and the options that you mentioned are presented for the Distribution Agent.
However, I can make changes to the tables included in the Publication regardless of the frequency with which the Distribution Agent runs and that is what I expected because the Distribution Agent is unaware of any changes to a Publication - it just pushes (or pulls) the published articles to the Subscriber after a new snapshot has been generated.
What error do you get when you try to modify tables on the Publisher?
February 26, 2014 at 8:42 am
You can not alter the table with out dropping and re-adding them , having distribution job running or not is irrelevant .
Steps to follow :
1. Remove the Table from the publication .
2. Add the filed in table
3. Re-add only one table which you changed .
4. Make sure immediate sync or anonymous is false .
5. Run the snapshot to pick only the table change you did not the whole snapshot publication .
February 26, 2014 at 9:06 am
sqldba725 (2/26/2014)
You can not alter the table with out dropping and re-adding them , having distribution job running or not is irrelevant .
Err...yes you can, I've tested that scenario today.
February 26, 2014 at 9:29 am
If you attempt to modify a table that's currently being replicated, you will receive the following error
- Unable to modify table.
Cannot drop the table 'dbo.ts-services' because it is being used for replication.
To obtian a list of table that are replicated you can run:select * from sys.objects where is_published = 1
To get around it you have to remove the article from the publication, make the change, then add it back into the publication.
How were you able to do this in your test?
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
February 26, 2014 at 9:59 am
You are trying to drop the table; that's not modifying it. The OP wanted to add a field (column)...that's what I did in my test. It's also possible to modify the the replicated table directly at the Subscriber although of course any modification will be lost when a new snapshot is applied.
Regards
Lempster
February 26, 2014 at 6:00 pm
To add a new column to a table and include it in an existing publication, you'll need to use ALTER TABLE <Table> ADD <Column> syntax at the publisher. By default the schema change will be propagated to subscribers, publication property @replicate_ddl must be set to true. The column must allow NULL values or include a default constraint. See Make Schema Changes on Publication Databases for more information.
February 26, 2014 at 7:48 pm
@Lempster and @brandon - quite right, my ID10T error. I am fully aware of the flag in the publication options to replicate schema changes, however as a quick test I used the GUI to make the change to the table (and MS's way of doing so is to create a temp copy of the table with the new change, copy everything into the temp table, drop the old table, and rename the temp to the original table). This is what generated the error I posted. My bad for not dotting my I's and crossing my T's - very lame :w00t:
Thanks for pointing this out.
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
February 27, 2014 at 2:20 am
Phew! Thought I was going mad for a minute. :crazy:
February 28, 2014 at 9:08 am
[font="Verdana"]What is the error you are facing , you can alter the Table if there is no index exists on the column you are altering and if any index exists the only change it will allow is increasing the datatype limit .
So if you are changing Datatype varchrar(200) to nvarchar(200) it will fail and if you run varchar(100) to varchar(200) it will successfully execute .
Please post error ! [/font]
February 28, 2014 at 9:09 am
[font="Verdana"]What is the error you are facing , you can alter the Table if there is no index exists on the column you are altering and if any index exists the only change it will allow is increasing the datatype limit .
So if you are changing Datatype varchrar(200) to nvarchar(200) it will fail and if you run varchar(100) to varchar(200) it will successfully execute .
Please post error ! [/font]
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply