Changing column length of a replicated table

Can I increase the length of a varchar column of table involved in transactional replication without dropping and recreating publication/subscription?

Any help/short-cuts/undocumented features greatly appreciated.

Regards

Opal

Are you using SQL Server 2005? If so, you can turn on @.replicate_ddl option (set it to 1) for a publication then use regular "ALTER TABLE ... ALTER COLUMN ..." DDL syntax to increase the length of the column, the DDL change will be automatically replicated to subscriber by replication. (@.replication_ddl options is automatically turned on if you use management studio to create the publication)

Hope that helps,

Zhiqiang Feng

|||

Thank you Zhiqiang for your reply, but sorry we're using 2000.

Opal

|||

Sorry there is no easy workaround in SQL Server 2000. The only alternative is that you can use sp_repldropcolumn then sp_repladdcolumn to drop and re-create the column, but that way you will lose all the data for that column.

Thanks,

Zhiqiang Feng

change timestamp from null to not null

Hi,
Would dropping the column and recreating it with the 'not
null' clause be the advisable way to do it?
Many thanks,
Osk

>--Original Message--
>Hi,
>I have a table with a timestamp column which allows nulls.
>I wanted to
>ALTER TABLE [dbo].[MyTbl] ALTER COLUMN [MyClmn] [timestamp]
>NOT NULL
>but it gives me msg 4927 - Cannot alter column 'MyClmn' to
>be data type timestamp.
>Is there any elegant/easy way around this?
>--
>Many thanks,
>Osk
>.
>
Osk wrote:[vbcol=seagreen]
> Hi,
> Would dropping the column and recreating it with the 'not
> null' clause be the advisable way to do it?
>
If you need to preserve the data in the table, create a second table,
copy the data, change the first table DDL and then migrate the data
back.
David Gugick
Imceda Software
www.imceda.com
|||Hi David,
Thanks for your answer. Can you please tell me why would I
lose any data except the old timestamp values (which seems
to be inevitable anyway) by dropping and
redefining/recreating the timestamp column?
Many thanks,
Osk

>--Original Message--
>Osk wrote:
>If you need to preserve the data in the table, create a
second table,
>copy the data, change the first table DDL and then migrate
the data
>back.
>--
>David Gugick
>Imceda Software
>www.imceda.com
>.
>
|||anonymous@.discussions.microsoft.com wrote:
> Hi David,
> Thanks for your answer. Can you please tell me why would I
> lose any data except the old timestamp values (which seems
> to be inevitable anyway) by dropping and
> redefining/recreating the timestamp column?
>
I guess it really doesn't matter if you lose the data in the column.
David Gugick
Imceda Software
www.imceda.com
|||Yes, I lose the timestamp data in the column, but the rest
of the table data should be remaining intact. And from this
perspective the result of using either the drop-
redefine/recreate method or the export/import method would
be the same, except that the latter takes more effort to
implement.
Thanks,
Osk

>--Original Message--
>anonymous@.discussions.microsoft.com wrote:
>I guess it really doesn't matter if you lose the data in
the column.
>--
>David Gugick
>Imceda Software
>www.imceda.com
>.
>

change timestamp from null to not null

Hi,
Would dropping the column and recreating it with the 'not
null' clause be the advisable way to do it?
Many thanks,
Osk

>--Original Message--
>Hi,
>I have a table with a timestamp column which allows nulls.
>I wanted to
>ALTER TABLE [dbo].[MyTbl] ALTER COLUMN [MyClmn] [timestamp]
>NOT NULL
>but it gives me msg 4927 - Cannot alter column 'MyClmn' to
>be data type timestamp.
>Is there any elegant/easy way around this?
>--
>Many thanks,
>Osk
>.
>Osk wrote:[vbcol=seagreen]
> Hi,
> Would dropping the column and recreating it with the 'not
> null' clause be the advisable way to do it?
>
If you need to preserve the data in the table, create a second table,
copy the data, change the first table DDL and then migrate the data
back.
David Gugick
Imceda Software
www.imceda.com|||Hi David,
Thanks for your answer. Can you please tell me why would I
lose any data except the old timestamp values (which seems
to be inevitable anyway) by dropping and
redefining/recreating the timestamp column?
Many thanks,
Osk

>--Original Message--
>Osk wrote:
>If you need to preserve the data in the table, create a
second table,
>copy the data, change the first table DDL and then migrate
the data
>back.
>--
>David Gugick
>Imceda Software
>www.imceda.com
>.
>|||anonymous@.discussions.microsoft.com wrote:
> Hi David,
> Thanks for your answer. Can you please tell me why would I
> lose any data except the old timestamp values (which seems
> to be inevitable anyway) by dropping and
> redefining/recreating the timestamp column?
>
I guess it really doesn't matter if you lose the data in the column.
David Gugick
Imceda Software
www.imceda.com|||Yes, I lose the timestamp data in the column, but the rest
of the table data should be remaining intact. And from this
perspective the result of using either the drop-
redefine/recreate method or the export/import method would
be the same, except that the latter takes more effort to
implement.
Thanks,
Osk

>--Original Message--
>anonymous@.discussions.microsoft.com wrote:
>I guess it really doesn't matter if you lose the data in
the column.
>--
>David Gugick
>Imceda Software
>www.imceda.com
>.
>

Change maintenance plan owner

I would like to change the owner of several maintenance plans. I can't seem
to find a way to that without recreating each plan while connected as the new
owner. Is there a method similar to changing a job's owner via the job's
properties or a database's by sp_changedbowner?
ThanksJim,
Sorry, I don't know a neat way to change the maintenance plan owner. (In
SQL Server 2000, you can go through the process to modify system tables and
change the 'owner' column of msdb.dbo.sysdbmaintplans (although I don't
recommend it) but in SQL Server 2005 that avenue has been closed.)
You can, of course, change the job owner that runs the maintenance plan as
you already described. Is there a reason that the maintenance plan owner
needs to be changed? What side effects are you experiencing?
RLF
"Jim Early" <JimEarly@.discussions.microsoft.com> wrote in message
news:DF28A436-C2D0-4F86-9BC7-5591A164A464@.microsoft.com...
>I would like to change the owner of several maintenance plans. I can't
>seem
> to find a way to that without recreating each plan while connected as the
> new
> owner. Is there a method similar to changing a job's owner via the job's
> properties or a database's by sp_changedbowner?
> Thanks|||Changing the owner of the job only works until the maintenance plan is
modified, then the jobs reverts back to the owner of the maintenance plan.
You might review this article:
http://sqlblogcasts.com/blogs/acalvett/archive/2007/12/30/the-job-whose-owner-kept-coming-back.aspx
"Russell Fields" wrote:
> Jim,
> Sorry, I don't know a neat way to change the maintenance plan owner. (In
> SQL Server 2000, you can go through the process to modify system tables and
> change the 'owner' column of msdb.dbo.sysdbmaintplans (although I don't
> recommend it) but in SQL Server 2005 that avenue has been closed.)
> You can, of course, change the job owner that runs the maintenance plan as
> you already described. Is there a reason that the maintenance plan owner
> needs to be changed? What side effects are you experiencing?
> RLF
> "Jim Early" <JimEarly@.discussions.microsoft.com> wrote in message
> news:DF28A436-C2D0-4F86-9BC7-5591A164A464@.microsoft.com...
> >I would like to change the owner of several maintenance plans. I can't
> >seem
> > to find a way to that without recreating each plan while connected as the
> > new
> > owner. Is there a method similar to changing a job's owner via the job's
> > properties or a database's by sp_changedbowner?
> >
> > Thanks
>
>|||Interesting. Thanks, RLF
"jed" <jed@.discussions.microsoft.com> wrote in message
news:96DC37A2-DD29-4EE2-A89D-F24A8DC41981@.microsoft.com...
> Changing the owner of the job only works until the maintenance plan is
> modified, then the jobs reverts back to the owner of the maintenance plan.
> You might review this article:
> http://sqlblogcasts.com/blogs/acalvett/archive/2007/12/30/the-job-whose-owner-kept-coming-back.aspx
> "Russell Fields" wrote:
>> Jim,
>> Sorry, I don't know a neat way to change the maintenance plan owner. (In
>> SQL Server 2000, you can go through the process to modify system tables
>> and
>> change the 'owner' column of msdb.dbo.sysdbmaintplans (although I don't
>> recommend it) but in SQL Server 2005 that avenue has been closed.)
>> You can, of course, change the job owner that runs the maintenance plan
>> as
>> you already described. Is there a reason that the maintenance plan owner
>> needs to be changed? What side effects are you experiencing?
>> RLF
>> "Jim Early" <JimEarly@.discussions.microsoft.com> wrote in message
>> news:DF28A436-C2D0-4F86-9BC7-5591A164A464@.microsoft.com...
>> >I would like to change the owner of several maintenance plans. I can't
>> >seem
>> > to find a way to that without recreating each plan while connected as
>> > the
>> > new
>> > owner. Is there a method similar to changing a job's owner via the
>> > job's
>> > properties or a database's by sp_changedbowner?
>> >
>> > Thanks
>>|||I encountered the same issue with the Maintenance Plan, when I made a change
to the MaintPlan, the Job changed to that of the owner of the MaintPlan.
According to some reading I have been doing, there really isnâ't a way to
change the Maintenance Plan Owner yet, I do understand why the MaintPlan
owner needs to be changed. In my case, the old DBA has been moved to another
section and no longer have rights to the SQL Server yet, when a change is
made to the MaintPlan, the job defaults to his name and the job fails. Also,
if the person is no longer an employee of the company yet, he created the
plans under his account, the MaintPlan defaults to his account or the account
he used when in SQL.
What I did to change the Owner of all Maintenance Plans in SQL 2005 was, if
you use windows authentication in SQL â'run asâ' the SQL account that is the
manager of SQL or connect to SQL using the SQL Account that manages your SQL.
From there, modify the Maintenance Plan, such as rename it, then rename it
back; the MaintPlan will assume the account you are using as the â'ownerâ'.
This may be tedious but it worksâ?¦
"Jim Early" wrote:
> I would like to change the owner of several maintenance plans. I can't seem
> to find a way to that without recreating each plan while connected as the new
> owner. Is there a method similar to changing a job's owner via the job's
> properties or a database's by sp_changedbowner?
> Thanks|||/*Here's how to change the owner of a maintenance plan to dbo in SQL Server
2005*/
--to find the name and owner of the maintenance plan
--select * from msdb.dbo.sysdtspackages90
--to find the sid you want to use for the new owner
--select * from sysusers
UPDATE
[msdb].[dbo].[sysdtspackages90]
SET
[ownersid] = 0x01
WHERE
[name] = 'MaintenancePlan'|||/*Here's how to change the owner of a maintenance plan to dbo in SQL Server
2005*/
--to find the name and owner of the maintenance plan
--select * from msdb.dbo.sysdtspackages90
--to find the sid you want to use for the new owner
--select * from sysusers
UPDATE
[msdb].[dbo].[sysdtspackages90]
SET
[ownersid] = 0x01
WHERE
[name] = 'MaintenancePlan'
"Jim Early" wrote:
> I would like to change the owner of several maintenance plans. I can't seem
> to find a way to that without recreating each plan while connected as the new
> owner. Is there a method similar to changing a job's owner via the job's
> properties or a database's by sp_changedbowner?
> Thanks

Change maintenance plan owner

I would like to change the owner of several maintenance plans. I can't seem
to find a way to that without recreating each plan while connected as the ne
w
owner. Is there a method similar to changing a job's owner via the job's
properties or a database's by sp_changedbowner?
ThanksJim,
Sorry, I don't know a neat way to change the maintenance plan owner. (In
SQL Server 2000, you can go through the process to modify system tables and
change the 'owner' column of msdb.dbo.sysdbmaintplans (although I don't
recommend it) but in SQL Server 2005 that avenue has been closed.)
You can, of course, change the job owner that runs the maintenance plan as
you already described. Is there a reason that the maintenance plan owner
needs to be changed? What side effects are you experiencing?
RLF
"Jim Early" <JimEarly@.discussions.microsoft.com> wrote in message
news:DF28A436-C2D0-4F86-9BC7-5591A164A464@.microsoft.com...
>I would like to change the owner of several maintenance plans. I can't
>seem
> to find a way to that without recreating each plan while connected as the
> new
> owner. Is there a method similar to changing a job's owner via the job's
> properties or a database's by sp_changedbowner?
> Thanks|||Changing the owner of the job only works until the maintenance plan is
modified, then the jobs reverts back to the owner of the maintenance plan.
You might review this article:
http://sqlblogcasts.com/blogs/acalv...oming-back.aspx
"Russell Fields" wrote:

> Jim,
> Sorry, I don't know a neat way to change the maintenance plan owner. (In
> SQL Server 2000, you can go through the process to modify system tables an
d
> change the 'owner' column of msdb.dbo.sysdbmaintplans (although I don't
> recommend it) but in SQL Server 2005 that avenue has been closed.)
> You can, of course, change the job owner that runs the maintenance plan as
> you already described. Is there a reason that the maintenance plan owner
> needs to be changed? What side effects are you experiencing?
> RLF
> "Jim Early" <JimEarly@.discussions.microsoft.com> wrote in message
> news:DF28A436-C2D0-4F86-9BC7-5591A164A464@.microsoft.com...
>
>|||Interesting. Thanks, RLF
"jed" <jed@.discussions.microsoft.com> wrote in message
news:96DC37A2-DD29-4EE2-A89D-F24A8DC41981@.microsoft.com...[vbcol=seagreen]
> Changing the owner of the job only works until the maintenance plan is
> modified, then the jobs reverts back to the owner of the maintenance plan.
> You might review this article:
> http://sqlblogcasts.com/blogs/acalv...oming-back.aspx
> "Russell Fields" wrote:
>