Error Editing Step in Job (SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64))

On windows 2008 os and sql server 2008 r2 64 bit it works if you run at command prompt:


C:\WINDOWS\SysWOW64\regsvr32 "C:\Program Files\Microsoft SQL Server\100\DTS\Binn\dts.dll"


On Windows 7 with SQL Server 2008 r2 run as admin :

regsvr32 "C:\Program Files\Microsoft SQL Server\100\DTS\Binn\dts.dll"

So I run this at the command line to fix the problem?

Sure - that's what I did as well based on:
http://social.msdn.microsoft.com/Forums/en-CA/sqlintegrationservices/thread/049139d1-8721-486a-9017-e7d56f0c808f

I am running SSMS on a 64bit workstation Dude.

Error message reads:

The module, "C:\Program Files\Microsoft SQL Server\100\DTS\Binn\dts.dll" was loaded but the call to DllRegisterServer failed with error code 0x80070005.

It did not work Icohan!

This is a SSMS issue not a server issue.  At least I don't think so.  I exit out of SSMS and restart it and I can then edit the job steps.

"I moved several jobs from one instance to another via creating scripts and running them on the target machine.  I was able to edit a few and then I started getting the error:"

From this initial statement was hard to predict that this was done on a "64bit workstation Dude.' .....dude:)

Anyway, if that's the case it may be just because they were moved and the dts guid on the source is different than the new guid on the target and as (I guess) we are aware SSMS cache is not self refreshing very well.
What I mean is that unless you quit SSMS in between the two processes you may see the error. If you still have one job left with one DTS try following - it looks extreme but...:

script at source, save script as file, quit SSMS
start SSMS, connect to target, run the script from file, quit SSMS
start SSMS connect to target try edit and in my opinion this should work.

The title of the question is:
Error Editing Step in Job (SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64))

I think X64 intimates 64 bit...but hey, it does not stay my workstation was 64 bit, so point taken...

Even after I quit and restart SSMS the problem crops up after I edit a few job steps.  Sometimes as little as 2 or 3 jopb step edits and POP, the error message comes up.  Once I quit SSMS and restart it the error goes away for a time.

That's really bizarre...is the error coming back editing exactly the same SQL job and step(s) or is always on new jobs/steps
Now this sounds silly but is your SSMS workstation client installed from the same 2008 R2 or is it different version? I'm running on Win7 x64 against 2008 R2 and never had similar issue even though I recently had to migrate lots of jobs running dts packages from 2005 to 2008.

Here is my workstation info, it is R2:
Microsoft SQL Server Management Studio                                    10.50.1600.1
Microsoft Analysis Services Client Tools                                    10.50.1600.1
Microsoft Data Access Components (MDAC)                                    6.1.7600.16385
Microsoft MSXML                                    3.0 4.0 5.0 6.0
Microsoft Internet Explorer                                    8.0.7600.16385
Microsoft .NET Framework                                    2.0.50727.4952
Operating System                                    6.1.7600

Ahh man, this is starting to sound like I have to uninstall and reinstall my SQL Server Client software, something got screwed up...SMH

If is just client software it is inconvenient but that should not be such a big deal right? Don't want to sound pessimistic but...the problem is - what hapens if it comes back after re-installing...

Can you try maybe from different workstation that has similar SSMS versions?

That I can do.  I will ask a colleague to try to edit a few of the jobs.   Our workstation configurations are identical.

I experience the same problem.  I am running the same version of SQL as you on a Windows Small Business Server 2011 standard.  Have you found any solution yet?

This rolls out the SQL server itself as it’s clearly connected to the client tools installed on your workstation. Other things to consider are differences between the two workstations in software installed and service packs/updates but that in my opinion only if uninstall/reinstall SSMS is not working. I believe It's not worth it to get to the roots of it if simple uninstall/reinstall solves it.

Testing the solution now...

regsvr32 "C:\Program Files\Microsoft SQL Server\100\DTS\Binn\dts.dll" as Administrator worked for me.