Decimal limited to 4 digits to right of decimal?

I need to store decimal values: decimal(20,15) in my SQL Server 2005 database.

I load data from flat file, convert it using Data Conversion Task to decimal(with scale: 15) and try to save it using OLE DB Destination.

It works fine for 4 digits after the decimal (like 1.1234), but always failes for more than 4 digits (1.12345).

Is the decimal limited to scale 4 ?

Thank you for your help!

Anna

Nope. Should work. What is the error?|||

I got:

Error code: 0x80004005. An OLE DB record is available. Source: "Microsoft SQL Native Client"
Hresult: 0x80004005 Description: "Invalid character value for cast specification".

Error: There was an error with input column "MyDecimalColumn" (10464) on input "OLE DB Destination Input" (10388).
The column status returned was: "Conversion failed because the data value overflowed the specified type."

Anna

|||That would indicate the destination in SQL is two small. What is it defined as?

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 stops without messages

Have a task that has 120 tables (components) that I am running in debug mode. Just over half of the components run which takes btrieve db and converts into a sybase db. When it stops running there are a few components that are yellow, the components which completed are green and the rest are still white because they have ran yet. The problem is there is not a message to indicate as to why it stopped. I've broken up the task into two tasks and also tried making two projects. The same situation happens at the same point. Our dbas have checked the database to ensure that's fine and it is. Is there some sort of limitation in how many components can be run in debug mode?

No, but enginethreads may be limiting you here. Read this and see if it helps: http://blogs.conchango.com/jamiethomson/archive/2005/10/02/2227.aspx

-Jamie

|||Thanks for the response. I read the link and tried making a few changes to the enginethreads but no luck. In my original project I had two tasks that were linked and the first one ran without issues and the next task is where it only did the couple of tables. I created a new project and added the package to the new project then deleted the first task. Now that it's a separate project I still have the same issue. Because I copied the original package could there still be some sort of hooks that won't change because of the copy and it will still associate the number of components with the original package? The reason for this question is that I changed the enginethreads to be the max of 60 and when I ran it came back with a message that the required amount of threads in the pipeline were 121 and the max allowed was 64. I was thinking that because the package was copied could the pipeline info still show as 121 instead of the actually component count? Each task originally had about 60 components. Can I delete lines from the xml file that the package creates?|||

I found this log:

04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters: 4 supplied
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID = 3368
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags = 0x0
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr = 0x0100C5D0
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir = <NULL>
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExceptionRecordPtr = 0x00000000
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr = 0x00000000
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile = <NULL>
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName = <NULL>
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName = <NULL>
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11 not used
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7 not used
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump completed: C:\Program Files\Microsoft SQL Server\90\Shared\ErrorDumps\SQLDmpr0017.mdmp
04/04/06 14:46:43, ACTION, DtsDebugHost.exe, Watson Invoke: No

|||

That looks like it could be a SQL Server issue - that's where SQLDUMPER files come from unless I'm mistaken.

-Jamie

|||

Thanks again Jamie. With my post before the log info just wondered what your opinion was on that? I read the link and tried making a few changes to the enginethreads but no luck. In my original project I had two tasks that were linked and the first one ran without issues and the next task is where it only did the couple of tables. I created a new project and added the package to the new project then deleted the first task. Now that it's a separate project I still have the same issue. Because I copied the original package could there still be some sort of hooks that won't change because of the copy and it will still associate the number of components with the original package? The reason for this question is that I changed the enginethreads to be the max of 60 and when I ran it came back with a message that the required amount of threads in the pipeline were 121 and the max allowed was 64. I was thinking that because the package was copied could the pipeline info still show as 121 instead of the actually component count? Each task originally had about 60 components. Can I delete lines from the xml file that the package creates?

Once again thanks for your responses.

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

debugging in SSIS

I have a script task in SSIS package. I want to debug the code . but even after setting break points control does not go through the code. So am using msgbox for debuggin purpose ( but its really painfull) can anybody guide me on this.

Thanks,

Prash

first I suggest posting to the SSIS forum

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=80&SiteID=1

Second, this absolutely should be working.

With the VSA designer opened, f9 to set a breakpoint on some code.

when the package executes (from within the design environment, executing outside the designer will not bring up a jit type debugger) the breakpoint should hit.

If you continue to see this problem, post to the SSIS forum to see if anyone can think of things to try.

|||Moving to the right forum|||

prashant550806 wrote:

I have a script task in SSIS package. I want to debug the code . but even after setting break points control does not go through the code. So am using msgbox for debuggin purpose ( but its really painfull) can anybody guide me on this.

Thanks,

Prash

It isn't possible at the moment.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=359859&SiteID=1|||Just a minor point of clarification - you can debug script tasks (in the Control Flow), but you can't debug script components (in the Data Flow). I'm guessing from your problem that you are trying to debug a script component, not a script task.|||

I have tried both script task in control flow as well as script component in data flow but wasnt successful

regards,

Prash

|||

its pitty that SSIS does not support debug mode in script component/task...

Prash

|||

Phil Brammer wrote:

prashant550806 wrote:

I have a script task in SSIS package. I want to debug the code . but even after setting break points control does not go through the code. So am using msgbox for debuggin purpose ( but its really painfull) can anybody guide me on this.

Thanks,

Prash

It isn't possible at the moment.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=359859&SiteID=1

Phil,

That's not true. It is not possible to debug script components but it IS possible to debug script tasks - which is what the original poster said he wanted to do.

-Jamie

|||

prashant550806 wrote:

its pitty that SSIS does not support debug mode in script component/task...

Prash

It does. You CAN debug script tasks - as is stated elsewhere in this thread.

-Jamie

Debugging and ActiveX Script Task in a DTS Package running on SQL Server 2005

I have a DTS package that I brought over from SQL server 2000 in to SQL Server 2005. I have installed all of the legacy components to run the DTS packages but I need to debug an ActiveX script task. In SQL Server 2000 I could turn on Just-In-Time debugging and use the stop operator (in my vbscript) to break the running script and launch the debugger.

I don't see how to do this in SQL Server 2005 Management Studio. Is it possible to debug a script object in a DTS package running in SQL Server 2005?

Jay Abbott

I have not tried, but another way to stop execution is to use a MsgBox. Whilst it is paused, you could attach the debugger to the DTS process.

I would bin the ActiveX Script, or leave it in DTS. The diagnostic information is absolutely non-existent coming out of the SSIS ActiveX Script Task, and for my money that is unacceptable in a system. Leaving it in DTS is quite easy, and perhaps call the DTS from SSIS to allow you to migrate some functions in your process. Just the fact that no error information is forthcomming in the event of a failure is enough for me to avoid using it entirely.

Debugging a script component task?

How to debug a Script Component task?

For instance, I’ve got a Input0_ProcessInputRow procedure and I’d like to see what happen when compiler reach this line:

dFecha = Left(Row.Column19, 4) & "-" & Mid(Row.Column19, 5, 2) & "-" & Right(Row.Column19, 2)

I’ve put a toogle breakpoint there and then saved but when I run the package to ignore at all.

This topic has been already discussed in these newsgrups but I still have doubts.

Thanks a lot for any advice or clarification

Unfortunately you can't debug script components with breakpoints as you can in the script task.

Your best option is to fire events from within the script component that output teh values that you are interested in.

Not great but for now its what we're stuck with I'm afraid.

-Jamie

|||

Thanks Jamie.

Anyway, I tried to allocate a MessageBox.Show... method but it did not work....

According to DarrenSqlis you can do that with Script Task no with Script Component task

|||

Correct. Message box only works in script task as well.

-Jamie

|||

So that, as you said we are totally stuck. I'll use variables in order to see anything

seeya

|||

Try firing OnInformation events containing the information that you are interested in.

-Jamie

|||

are you talking about Event Handlers tab and then choose Data Flow task and to capture oninformation event and do some stuff there?

thanx

|||

You can fire events from within the script component that will then be caught by the eventhandlers. Here's some code that would output the value of a variable:

ComponentMetaData.FireInformation(1, "MyScriptComponent", "VariableName=" + CStr(Me.Variables.VariableName), "", 0, True)

You can change it to output whatever you like.

Once the eventhandler catches the fired event then you can do whatever you like with the value.

-Jamie

|||

hi again,

I suppose that 'MyScripComponent' is equal to the name of my script, in my case "ScriptMain", isn't it? Or maybe the name of my Data Flow component?

Where you put VariableName are you referring a variable defined in my package.

thanks a lot

|||

You can put whatever you like for most of the parameters. Where it says "MyScriptComponent" you can even leave that blank if you want. The important bit is what you are outputting in the "Description" parameter.

And yes, VariableName is a variable defined in your package and referenced in ReadWritevariables. It doesn't have to be a variable though - that was just an example. You can output whatever you like (e.g. a value in your incoming row or a calculated value)

Just go into your script component and type:

"Componentmetadata.FireInformation("

and let intellisense help you from there.

-Jamie

|||Thanks for everything!|||msgbox.Show(string) does not work... But msgbox(string) should work...|||

hi TGnat,

you're right, that works. Thanks a lot I hadn't though it