SSIS - Database Transfer Wizard - @flags parameters is not valid

  • I'm trying to use copy database wizard to make a copy of a SQL Server 2005 database (9.0.3042) on a SQL Server 2012 machine (11.0.2100). I'm using the "SQL Management Object method" so that the orginal database can remain online. When I get to the final step I recieve the following error:

    - Start SQL Server Agent Job (Error)


    * Create failed for JobStep 'CDW_KC4DATABASE_KCCDB_0_Step'. (Copy Database Wizard)

    The @flags parameter is not valid for a job step of type 'SSIS'. (Microsoft SQL Server, Error: 14545)

    I can't seem to find anything on the internet regarding "@flags parameter is not valid". Of course the two links provided in the error log that go to microsoft's site are totally useless. The full error message follows:

    Performing operation

    - Add log for package (Success)

    - Add task for transferring database objects (Success)

    - Create package (Success)

    - Start SQL Server Agent Job (Error)


    * Create failed for JobStep 'CDW_KC4DATABASE_KCCDB_0_Step'. (Copy Database Wizard)

    For help, click:



    An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)


    The @flags parameter is not valid for a job step of type 'SSIS'. (Microsoft SQL Server, Error: 14545)

    For help, click:

    - Execute SQL Server Agent Job (Stopped)

    Anyone have any insight?


  • Did you choose "detach/attach" or SMO? Couldn't you just schedule the package, or does the error come up during package creation?

    Query Shepherd

  • SMO; I want to allow the database to remain online.

    I can't finish the wizard to actually create the package; I get the error on the last step.



  • Just ran into this issue. I was using SSMS on my local machine, which has 2008R2, but the SQL Server itself is 2012. I logged into the server (RDP) and launched SSMS and followed the same steps; everything worked fine.

  • Joe, thanks for that insight. I bet that's what going on. I have both SMO 2008 R2 and SMO 2012 installed on my workstation. I can't remember exactly which one I was using, but I wouldn't be surprised if I was using the old one to try to manage a 2012 instance.

    Maybe there should be a warning when you try to connect that says:

    "hey dummy, do you know that you're trying to manage a 2012 instance with 2008 software? There will be problems".


    I just ended up taking it offline; but maybe this post will help someone in the future. Thanks for leaving the reply!

  • I am getting "The destination must be a SQL Server 2005 instance" when I do Copy Database through Copy Database Wizard.(RDP and launched SSMS in the source server)

    Source Server: Microsoft SQL Server 2005 - 9.00.5069.00 (Intel X86) (SP2) Enterprise Edition

    Destination Server: Microsoft SQL Server 2012 (SP1) Enterprise Edition (64-bit)

    Please help.


  • Did you try it from the destination server? As mentioned above, this is probably related to using older management server software to perform the copy. Try it from the 2012 server, it seems logical that the 2012 management software should be backwards compatible with copying data from 2005; but 2005 might not be able to copy data to a 2012 instance.

    Please post back if you find a solution; so far we're working in speculation only.

  • Hi,

    I had also the same problem and its solved magically.

    I simply closed all my instances of SSMS and Run the Copy database wizard once again.

    The package created successfully, Job created successfully and job executed successfully.



  • I am having the same / similar problem:

    Trying to use copy database wizard to move a database from an SQL 2008 R2 installation on server 2008 R2 to an SQL 2014 installation on a server 2012 machine. I'm using Win authentication on the source machine (where the Copy database command is running) and SQL authentication with the sa login for the destination server.

    Can anyone help?

  • Make sure you're using SSMS from the 2014 install.

  • Thanks for your help but if the database to be copied is on the older machine, how would I use the newer PC to copy it?

  • Thanks for your help but can you tell me how to access the old database (on my Server 2008R2 machine) from the new server (on a server 2012R2 machine)?

  • Maybe I'm making the wrong assumption, but I thought you were using the database transfer wizard to transfer a database from server A to server B. You should be able to access both the servers. Am I wrong about that? You could run SSMS from server A, or serer B. You could even run it from a 3rd computer. Were ever you are running it from, make sure it's the highest version (compared with the instances you have installed with server A and server B).

  • Your assumption was correct but I cannot install SQL 2014 on the older server without installing new dot net versions and other changes - which are not worth the time when we plan to retire this server as soon as the new one is operating OK. I would therefore need to do this from the new server, but how do I link its SQL server to the old server in order to copy the database?


  • Neil,

    I'm sorry, I'm not understanding. Take a look at this article:

    In it, it states you must specify the source and destination server. You would just use the instance names; so source;ServerA and Destination:ServerB. Are you not able to connect to them over the network?

    I would install SSMS on my desktop computer; make sure it's from the latest version you are using (like SQL 2014). You should be able to connect via SSMS to both ServerA and ServerB.


    To use the Copy Database Wizard, you must specify the following:

    The source server where the databases to be copied reside.

    The destination server to which the databases are to be copied or moved.

    The databases to be moved or copied.

    The name of a target database, if different than the name of the source database.

    The source database name can be use for the copied or moved database only if name conflicts do not exist on the destination server. If name conflicts exist, you must resolve them manually on the destination server before you can use the source database name there.

    Other objects to be copied or moved; for example, logins, shared objects from the master database, jobs and maintenance plans, and user-defined error messages.

    The schedule for the copy or move operation, if you want it to run at a later time.

    If you are not a system administrator, you must specify a SQL Server Agent Proxy account that has access to the Integration Services (SSIS) Package execution subsystem.

Viewing 15 posts - 1 through 15 (of 16 total)

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