If I open SSMS on my client machine, connect to our SQL server, and try and open a maintenance plan on there, I get this error:

TITLE: Microsoft SQL Server Management


Could not load file or assembly 'msddsp, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. (Microsoft.DataTransformationServices.Design)

------------------------------ BUTTONS:


If i try the same thing directly on the server, nothing happens (no errors or anything)


I had this error message whenever I opened a Maintenance Plan.

Was running:

  • Windows Server 2008 SP2
  • SQL Server 2008 R2 10.50.1617.0
  • SQL Server Management Studio 10.50.1617.0

I downloaded and installed SQL Server Management Studio SP1 (SQLManagementStudio_xxx_ENU) - didn't even upgrade the server itself, and was able to open up Managment Plans after that. Now I have:

  • SQL Server 2008 R2 10.50.1617.0
  • SQL Server Management Studio 10.50.2500.0

I noticed that after installing this, I have the correct version of msddsp installed into the GAC.

enter image description here

Otherwise, maybe this will work for you?:

| improve this answer | |

Make sure your machine is at the same SQL service pack level as the server.

| improve this answer | |
  • how can i do this? Is there a cmd i can run to see which version? – alex Jul 21 '10 at 11:52
  • if you have the database server installed locally, connect to it and do select @@version; if you only have the client tools, run Management Studio and do Help / About, check the version there against the server's copy. I'll bet it's lower. – SqlACID Jul 21 '10 at 16:22

The (to a beginner) oh so alluring Maintenance Plans actually use a completely different component (SQL Server Integration Services, SSIS) to package and execute the plans.

This means that the SSIS and MSSQL installations used to create such plans must match the versions of the SSIS and MSSQL installations that execute them - yes, MSSQL and SSIS are two different programs.

After having run into this utter failure cr*p multiple times on both production and testing servers, I have ditched it altogether and am now using efficient, simple to use, and completeley controlled SQL Agent jobs.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.