SQL Server Home
MSIT-MSO: Invalid parameter @schedule_uid is added to job script (SQL 2005) when scripted out using SSMS 2008
as By Design
1/31/2008 10:47:27 PM
User(s) can reproduce this bug
If a job has scedule defined and its created in SQL Server 2005, when you script it out using SSMs 2008, the job script will have Invalid parameter @schedule_uid is added for the call of sp_add_jobschedule. Due to this the script fails when run against 2005 server.
The same issue occurs when you try to migrate jobs from 2008 server to 2005 server using 'Transfer Jobs Task' of SSIS 2008. The task fails with error
[Transfer Jobs Task] Error: Execution failed with the following error: "@schedule_uid is not a parameter for procedure sp_add_jobschedule.
Warning: Non-existent step referenced by @on_success_step_id.
Warning: Non-existent step referenced by @on_fail_step_id.
Warning: Non-existent step referenced by @on_fail_step_id.".
SQL Server Private Build - Pre-CTP6
Tools (SSMS, Agent, Profiler, etc.)
Win2003 Enterprise Server (SP2)
Operating System Language
Steps to Reproduce
1. Connect to a SQL Server 2005 server using SSMS 2008.
2. Try to script out a job that has schedule defined for it
Invalid parameter @schedule_uid is added for the call of sp_add_jobschedule
The extra parameter @schedule_uid should not be there.
to post a comment.
Please enter a comment.
on 9/15/2009 at 2:42 AM
How do get rid of this "Warning: Non-existent step referenced by @on_success_step_id.
I am getting this warning when am trying to deploy the SQL job on the target server using SQL script.
on 5/19/2008 at 3:07 PM
Buck, this isn't true:
"For instance, you can set the option to script as 2000, 2005 and now 2008, which is the default. If you change that setting, your script will function properly."
Even if you set the option to script to 2005, and you right-click a job on a 2005 instance and script it, you get a script that is only compatible with SQL Server 2008. This is not going to make it very easy to manage downlevel instances!
on 5/8/2008 at 5:02 PM
I wanted to clarify what happened with this issue. You reported that when you scripted an object in a lower version of SQL Server than the tools that are installed, you get syntax in error for the lower system. We did find a bug that certain syntax would be rendered incorrectly in the script, and we've fixed that. However, the behavior isn't what you might expect, so I want to explain.
In Tools | Options, there is a setting that allows you to set the scripting "version" you want. For instance, you can set the option to script as 2000, 2005 and now 2008, which is the default. If you change that setting, your script will function properly.
We have these options since we can't always be certain of the use-case of the script. Consider that you might script an object on one server to re-create it on another. For that reason we always default the script to the version of SQL Server Management Studio. That way you could script a SQL Server 2000 object and re-create it on SQL Server 2008.
We do have the option setting for the case where you want to script the item on one version and keep it in that version.
Thanks for submitting!
Buck Woody, SQL Server Program Manager
on 2/22/2008 at 9:46 AM
We have fixed this bug in a post-ctp6 build of SQL Server 2008.
on 2/6/2008 at 12:54 PM
Thanks for the bug report. We are investigating this issue for SQL Server 2008.
to post a workaround.
Please enter a workaround.
© 2014 Microsoft