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.

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!

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]

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.

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.

debugging script task

Hi,

I'm trying to debug a Script Task. I set a breakpoint then start debug. I always get a COM Exception error:

unhandled exception occurred in DTAttach.exe[3332]

File position not valid for new breakpoint

Can someone suggest me something?

Thanks

I have found this workaround

If you assign the result of an expression to a DTSVariable, I always get an error. If you assign the result to a varaible and then assign this variable to a dtsVariable all is fine.

e.g.

Dts.Variables("bFTPIsEmpty").Value = IIf(fs.GetFiles("*.*").Length = 0, True, False) --> ERROR

THIS WORKS FINE

IsEmpty = CBool(IIf(fs.GetFiles("*.*").Length = 0, True, False))

Dts.Variables("bFTPIsEmpty").Value = IsEmpty

|||

Was facing the same issue even after trying all of the above.

Have found workaround for this annoying problem

Everytime you get this error, right click on the problematic project in solution explorer and select 'clean' and then select 'rebuild'

Debugging should then work ok.

ta

arun

|||

I've tried both workarounds and nothing! I have not variables assignments so that it's not the issue for sure! I get this error after I choose debugger: An unhandled exception of type 'System.Runtime.InteropServices.COMException' occurred in Microsoft.SqlServer.ScriptTask.dll. Additional information: File position not valid for new breakpoint. Then I select to continue and the process ends correctly...

Just later I found that by commenting out this two declarations I had but not using, the problem went away!

Imports System.Xml

Imports System.Xml.XmlDataDocument

debugging script task

Hi,

I'm trying to debug a Script Task. I set a breakpoint then start debug. I always get a COM Exception error:

unhandled exception occurred in DTAttach.exe[3332]

File position not valid for new breakpoint

Can someone suggest me something?

Thanks

I have found this workaround

If you assign the result of an expression to a DTSVariable, I always get an error. If you assign the result to a varaible and then assign this variable to a dtsVariable all is fine.

e.g.

Dts.Variables("bFTPIsEmpty").Value = IIf(fs.GetFiles("*.*").Length = 0, True, False) --> ERROR

THIS WORKS FINE

IsEmpty = CBool(IIf(fs.GetFiles("*.*").Length = 0, True, False))

Dts.Variables("bFTPIsEmpty").Value = IsEmpty

|||

Was facing the same issue even after trying all of the above.

Have found workaround for this annoying problem

Everytime you get this error, right click on the problematic project in solution explorer and select 'clean' and then select 'rebuild'

Debugging should then work ok.

ta

arun

|||

I've tried both workarounds and nothing! I have not variables assignments so that it's not the issue for sure! I get this error after I choose debugger: An unhandled exception of type 'System.Runtime.InteropServices.COMException' occurred in Microsoft.SqlServer.ScriptTask.dll. Additional information: File position not valid for new breakpoint. Then I select to continue and the process ends correctly...

Just later I found that by commenting out this two declarations I had but not using, the problem went away!

Imports System.Xml

Imports System.Xml.XmlDataDocument

Debug SP not stopping on Breakpoint

I was able to pull up a stored procudure in .Net using the Server Explorer. I
double clicked the SP to pull it up, added a few breakpoints, then I right
clicked on the SP, selected Step Through, then entered the parameter value.
There is no evidence that anything is happening or happened. How do I get the
yellow bar to show up so I can see it stepping through the SP?Troubleshooting tips for T-SQL Debugger in Visual Studio .NET
http://support.microsoft.com/newsgroups/default.aspx
AMB
"Mike L" wrote:
> I was able to pull up a stored procudure in .Net using the Server Explorer. I
> double clicked the SP to pull it up, added a few breakpoints, then I right
> clicked on the SP, selected Step Through, then entered the parameter value.
> There is no evidence that anything is happening or happened. How do I get the
> yellow bar to show up so I can see it stepping through the SP?|||Hi,
Additionally to AMB's Knowledge Base article, here is some others for your
reference
INF: Advanced Debugging of SQL Server Procedures
http://support.microsoft.com/?id=163451
Troubleshooting tips for T-SQL Debugger in Visual Studio .NET
http://support.microsoft.com/?id=817178
Debugging Stored Procedures
http://www.windowsitpro.com/Article/ArticleID/16356/16356.html
Sincerely yours,
Michael Cheng
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
This document contains references to a third party World Wide Web site.
Microsoft is providing this information as a convenience to you. Microsoft
does not control these sites and has not tested any software or information
found on these sites; therefore, Microsoft cannot make any representations
regarding the quality, safety, or suitability of any software or
information found there. There are inherent dangers in the use of any
software found on the Internet, and Microsoft cautions you to make sure
that you completely understand the risk before retrieving any software from
the Internet.

Debug SP not stopping on Breakpoint

I was able to pull up a stored procudure in .Net using the Server Explorer.
I
double clicked the SP to pull it up, added a few breakpoints, then I right
clicked on the SP, selected Step Through, then entered the parameter value.
There is no evidence that anything is happening or happened. How do I get th
e
yellow bar to show up so I can see it stepping through the SP?Troubleshooting tips for T-SQL Debugger in Visual Studio .NET
http://support.microsoft.com/newsgroups/default.aspx
AMB
"Mike L" wrote:

> I was able to pull up a stored procudure in .Net using the Server Explorer
. I
> double clicked the SP to pull it up, added a few breakpoints, then I right
> clicked on the SP, selected Step Through, then entered the parameter value
.
> There is no evidence that anything is happening or happened. How do I get
the
> yellow bar to show up so I can see it stepping through the SP?|||Hi,
Additionally to AMB's Knowledge Base article, here is some others for your
reference
INF: Advanced Debugging of SQL Server Procedures
http://support.microsoft.com/?id=163451
Troubleshooting tips for T-SQL Debugger in Visual Studio .NET
http://support.microsoft.com/?id=817178
Debugging Stored Procedures
http://www.windowsitpro.com/Article...6356/16356.html
Sincerely yours,
Michael Cheng
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
=============
This posting is provided "AS IS" with no warranties, and confers no rights.
This document contains references to a third party World Wide Web site.
Microsoft is providing this information as a convenience to you. Microsoft
does not control these sites and has not tested any software or information
found on these sites; therefore, Microsoft cannot make any representations
regarding the quality, safety, or suitability of any software or
information found there. There are inherent dangers in the use of any
software found on the Internet, and Microsoft cautions you to make sure
that you completely understand the risk before retrieving any software from
the Internet.

Debug SP not stopping on Breakpoint

I was able to pull up a stored procudure in .Net using the Server Explorer. I
double clicked the SP to pull it up, added a few breakpoints, then I right
clicked on the SP, selected Step Through, then entered the parameter value.
There is no evidence that anything is happening or happened. How do I get the
yellow bar to show up so I can see it stepping through the SP?
Troubleshooting tips for T-SQL Debugger in Visual Studio .NET
http://support.microsoft.com/newsgroups/default.aspx
AMB
"Mike L" wrote:

> I was able to pull up a stored procudure in .Net using the Server Explorer. I
> double clicked the SP to pull it up, added a few breakpoints, then I right
> clicked on the SP, selected Step Through, then entered the parameter value.
> There is no evidence that anything is happening or happened. How do I get the
> yellow bar to show up so I can see it stepping through the SP?
|||Hi,
Additionally to AMB's Knowledge Base article, here is some others for your
reference
INF: Advanced Debugging of SQL Server Procedures
http://support.microsoft.com/?id=163451
Troubleshooting tips for T-SQL Debugger in Visual Studio .NET
http://support.microsoft.com/?id=817178
Debugging Stored Procedures
http://www.windowsitpro.com/Article/...356/16356.html
Sincerely yours,
Michael Cheng
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.
This document contains references to a third party World Wide Web site.
Microsoft is providing this information as a convenience to you. Microsoft
does not control these sites and has not tested any software or information
found on these sites; therefore, Microsoft cannot make any representations
regarding the quality, safety, or suitability of any software or
information found there. There are inherent dangers in the use of any
software found on the Internet, and Microsoft cautions you to make sure
that you completely understand the risk before retrieving any software from
the Internet.