After the Windows server name been changed, when trying to
update or delete the jobs previously created in a SQL Server 2000 instance, you
may receive the following error message:
Error 14274:
Cannot add, update, or delete a job (or its steps or schedules) that originated
from an MSX server. The job was not saved.
This problem does not
occur for Microsoft SQL Server 7.0; however, you might receive this error
message when you upgrade a SQL Server 7.0 virtual server to a SQL Server 2000
virtual server even though you keep the same virtual server name. During the
upgrade process, you have to uncluster the SQL Server 7.0 virtual server. When
you uncluster the virtual server, it becomes a stand-alone instance of SQL
Server and it takes the node name, and you may receive the error message when
you change the name.
Back to the top
SQL Server 7.0 does not exhibit this problem because in the
msdb..sysjobs table, the field
originating_server stores the value
'(local)' referencing the local server. Therefore, no matter how the server
name is modified, the change does not affect the local server jobs.
Because SQL Server 2000 supports multi-instances, the
originating_server field contains the instance name in the format 'server\instance'.
Even for the default instance of the server, the actual server name is used
instead of '(local)'. Therefore, after the Windows server is renamed, these
jobs still reference the original server name and may not be updated or deleted
by the process from the new server name.
After an upgrade from SQL
Server 7.0 to SQL Server 2000, the
originating_server column is also updated for all existing jobs and the value
'(local)' is no longer used.
Back to the top
The best way to handle this problem after the rename
process is to follow these steps:
| 1. | Rename the server back to the original name. |
| 2. | Script out all of the jobs and then delete them. |
| 3. | Rename the server to the new name. |
| 4. | Add back the jobs by running the script generated from step
2. |
For additional information, see the "Multiserver
Administration" article in SQL Server Books Online.
Back to the top
Microsoft has confirmed this to be a problem in SQL Server
2000.
Back to the top
Help and Support
