Saturday, February 25, 2012

Debugging Woes

The following issue is happening a lot these days. For all the world it looks like a bug in BIDS:

I set a breakpoint in a Script Task (not a Script Component!) and the code dutifully stops on the breakpoint over and over again, as expected. (Please don't tell me about not being able to debug Script Components!)

At some point, when I run the package and hit the Script Task, the VSA editor opens as if it's going to take me to the breakpoint, but then it displays an error dialog box containing the following message:

Microsoft Visual Studio has lost its link to .
You work will be exported to C:\Documents and Settings\mgroh\My Documents when you quit the application

(Notice the space between "its link to" and the period in the first statement. It goes without saying that nothing is exported to My Documents.)

When I dismiss the dialog, execution resumes and the break point is ignored. In fact, breakpoints in all script tasks in the project are ignored.

Clearly, something is broken in the DTSX file, and is preventing VSA from finding the breakpoint. That's the only interpretation I can come up with for the "lost its link to" part of the message.

I have tried everything I can think of:
- Deleting all breakpoints and re-establishing the breakpoint
- Making a small change to the code to force VSA to re-evaluate the module
- Shutting down and re-opening the project
- Rebooting the computer (!!!!)

And NOTHING works. The module is just broken, and breakpoints it other Script Tasks don't work, either.

This really looks like a bug in SSIS, but I can't find anyone else who's complained of the same thing.

Any ideas? TIA!

- Mike

mike.groh wrote:

The following issue is happening a lot these days. For all the world it looks like a bug in BIDS:

I set a breakpoint in a Script Task (not a Script Component!) and the code dutifully stops on the breakpoint over and over again, as expected. (Please don't tell me about not being able to debug Script Components!)

At some point, when I run the package and hit the Script Task, the VSA editor opens as if it's going to take me to the breakpoint, but then it displays an error dialog box containing the following message:

Microsoft Visual Studio has lost its link to .
You work will be exported to C:\Documents and Settings\mgroh\My Documents when you quit the application

(Notice the space between "its link to" and the period in the first statement. It goes without saying that nothing is exported to My Documents.)

When I dismiss the dialog, execution resumes and the break point is ignored. In fact, breakpoints in all script tasks in the project are ignored.

Clearly, something is broken in the DTSX file, and is preventing VSA from finding the breakpoint. That's the only interpretation I can come up with for the "lost its link to" part of the message.

I have tried everything I can think of:
- Deleting all breakpoints and re-establishing the breakpoint
- Making a small change to the code to force VSA to re-evaluate the module
- Shutting down and re-opening the project
- Rebooting the computer (!!!!)

And NOTHING works. The module is just broken, and breakpoints it other Script Tasks don't work, either.

This really looks like a bug in SSIS, but I can't find anyone else who's complained of the same thing.

Any ideas? TIA!

- Mike

Mike,

No ideas I'm afraid no. I can only say that the use of script components/tasks can be ...errrr... flaky.

I usually try to recreate the script task and hope the problem goes away.

I know that doesn't help much but I wanted you to know that I feel your pain.

-Jamie

|||

Thanks for the confirmation that the Script Task may need re-creating. I was hoping it was something that you'd run into and had a nice little fix for. What a strange one! Flakey, to be sure!

If I detect any kind of pattern, such as actions that preceed this problem, I'll be sure to let you know. I'm thinking I'm doing something wrong surely, if this was a bug in SSIS or the VSA editor, other people would be complaining about it.

Thanks!

- Mike

|||I would sincearly appreciate it if someone with MSFT could assist with this bug. I am having this issue as well and it is very frustration to say the least. You spend a significant amount of time building a package, testing each step, then BAM! it's broken in the way described above and the only thing I can do is to start over, copy and paste? This is bad... I have to create a new project, create all new variables (making sure I don't accidentaly scope one in the wrong place) and so forth. Any more help or any ideas how to avoid this will be appreciated.|||Can you not just delete and re-create the script task, or is it at a package, or project level that you loose debug support?|||

Steven Barden wrote:

I would sincearly appreciate it if someone with MSFT could assist with this bug. I am having this issue as well and it is very frustration to say the least. You spend a significant amount of time building a package, testing each step, then BAM! it's broken in the way described above and the only thing I can do is to start over, copy and paste? This is bad... I have to create a new project, create all new variables (making sure I don't accidentaly scope one in the wrong place) and so forth. Any more help or any ideas how to avoid this will be appreciated.

Open up a Connect ticket.

https://connect.microsoft.com/SQLServer/Feedback|||

I am getting this error as well. I'm finding that I get the error message conditionally, depending on what line in my code I set the breakpoint on. If I set it on my "Try" line, then I DO NOT get the error. Once the debug window comes up, I can then set breakpoints where I really want to stop the code.

It's not ideal, but it is working for me.

If anyone has since found a resolution, I would greatly appreciate a response.

Thanks.

Mitch

|||I am having the same problem. is this still not fixed over a year later!!? Has anyone found out what the issue is. Just downloaded and installed sp1 for Team Suite as I have VS2005 Teamsuite installed, and I still can't debug my SSIS packages. If I put any break points in the Script code when I try to debug I get the message.

"SQL Server Integration Services Script Task has encountered a problem and needs to close. We are sorry for the inconvenience."

I click on close it then comes up with the "Microsoft Visual Studio has lost its link to..." error and it runs the package but doesn't stop at any break point. If I take out all break points it will run without this error. A couple of times I have managed to put in a single break point early in the package within a different script component which causes it to break... but at a completely different point within a completely different script component. It's so weird. Any help would be appreciated.

Hoots.
|||

I am running into this problem as well. Is Microsoft listening? It has been over 1 year since it was first posted.

I think this thread shows that enough people have been experiencing this issue. Isn't this time to pay attention to your paying customers?

By the way, dropping and re-creating script task doesn't help. I guess the only work around is to completely re-create the package, which is terrible and so problem-prone.

Thank you!

|||

Hi Michael,

The original issue that started this thread is a hard to reproduce problem in the VSA framework our script task and pipeline component are relying on for designing and executing scripts.

The latest issue with not hitting breakpoints is caused by a bug in our product that in some scenarios is unable to locate the original breakpoint. This only occurs when you have multiple scripts in the package. To workaround this you can try and set a breakpoint in the first script task that gets executed. When the VSA designer loads up all the script tasks in the package and hits that breakpoint you can add the other breakpoints in the other scripts. Unfortunately this is the only reliable workaround if you are unable to set breakpoints for now.

Also make sure you have SQL Server 2005 SP2 installed because there are some changes in the way scripts execute done in that service pack.

Hope this helps,

Silviu Guea [MSFT]

No comments:

Post a Comment