Can't debug DataFlow Script task

I have debugged a Control Flow script task and everything went as expected. I put a breakpoint somewhere in my script code, press F5 and execution will break there.

However, when I try the same in a Data Flow script, execution does not break! Moreover, when I reopen the code right after I closed VSA, the breakpoint is not there anymore...

Any help would be appreciated.

Regards,
Henk

[397 byte] By [HenkvJ.] at [2007-12-16]
# 1
Henk,
There's a simple answer to this. SSIS does not (yet) support breakpoints in a script component.

Regards
Jamie

JamieThomson at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 2
Well, thats a pitty...
HenkvJ. at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 3
Here are the suggestions that we were able to offer in BOL in place of debugging:

Debugging the Script Component

The Script component does not support the use of breakpoints. As a result, you cannot step through your code and examine values as the package runs. You can monitor the execution of the Script component by using the following methods:

  • Interrupt execution and display a modal message by using the MessageBox.Show method in the System.Windows.Forms namespace.

  • Raise events for informational messages, warnings, and errors. The FireInformation, FireWarning, and FireError methods display the event description in the Visual Studio Output window; however, the FireProgress method, as well as the Console.Write and Console.WriteLine methods, do not display any information in the Output window.

  • Log events or user-defined messages to enabled logging providers.

For information about raising events and logging, see Interacting with the Package in the Script Component.

DouglasL at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 4

I know this is a bit vague but its intentional.

How would you define 'debug' in the script component task. When speaking with people, the answers have varied more than I would have thought so I wanted to gather more feedback.

Thanks for your time
-MSFT SSIS

CraigGuyer at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 5

Personally I want to be able to set a breakpoint in the script and then be able to do all the normal things pne would do such as using the immediate and watch windows. Hovering over a variable to see its value etc... all the normal things you get with VS debugging.

-Jamie

JamieThomson at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 6
Same here really, debug the code as I would in VS. Breakpoints in code, and the ability to inspect values of variables, properties etc. Immediate Window support to test stuff as well. It does make debugging complex code very hard, such that it is sometimes easier to write a custom component for the debug capabilities. You then have the deployment work on top which is often a downside when (re)usage does not really warrant a full custom component to start with.
DarrenSQLIS at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 7

For me for the minimum usefull set of debugging functionality for a script component would be:

1:support for breakpoints,stepping through lines,restarting processing, ending processing from the debug enviroment.

2:immediate window that supports examining and changing values of variables that are within the scope of the current step. without this you are pretty much stuck with inserting message boxes everywhere in your code- what a mess.

lacking 1 and 2 above we basically are back to "desk checking" code on paper.

"Intellisense" functionality is definitely helpful but beyond my definition of "minimum".

Ken

kenambrose at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 8

Appreciate the feedback thus far, and rather concise.

How about macro support, in the true recording keystroke sense? I know its silly to ask if it would be useful as any feature is useful in some ways to someone, but would it greatly enhance functionality or usability?

I think where could be useful is pre-buit templates....which means if there were more templates you could choose from then perhaps the usefulness of macros are greatly reduced. For example the Script task could have a template for 'Writing To Windows Event Log' and there is some prefilled lines as the new script is created and then the package author adds/edits s appropriate. What other templates could be useful AND common.

SSIS MSFT

CraigGuyer at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 9

I have had the need to build winforms for user interfaces to run from a script component (input boxes are really quite limited) and I expect this to be a requirement for many of my integration scenarios.

Perhaps a template for a winform that could provide basic input/output of package variable values would be useful?

A winform that provided runtime feedback of processing (for example progress bars) and logged events would be useful in my scenarios, but that sounds more like a (really cool) container...

Ken

kenambrose at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 10

Craig,

What would the macro record? I don't see how you can record anything within the context of a script component, as what you do in SSIS is build things from components, yet the script component is at the same level, not a way to automate package building itself. Can you expand?

As for templates, I'm sure they woudl be usefull, be that the task or component, but to be honest if a template would be usefull, because it is repeated then I would look to put that in a custom component myself. The ability to add templates would perhaps help for when people do repeat code in these two, but how genric that woudl be outside of an organisation I am not sure.

Ken, The component would not want any user interaction, although the script task could. Saying that what you describe would be better implemented as an execution host, a fancy version of dtexecui perhaps, but trying to encapsulate that inside a package would not be a good idea I think.

DarrenSQLIS at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 11
Hi, regarding macros, thats a valid point. I guess I was thinking more of the script task rather than the script component. But even in the script component it could be handy to record a specific msgbox statement I want to just pop into scripts quickly and then tweak a bit. So, I conclude macros could be a handy nice to have but certainly not a major thing.
CraigGuyer at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 12

DouglasL wrote:

Interrupt execution and display a modal message by using the MessageBox.Show method in the System.Windows.Forms namespace.

here is my code:

MessageBox.Show ("Hello")

In the Input0_ProcessInputRow method.

Not popup shows up during execution.

I have added a DataViewer before the Script Compenent it doesn't stop either on the DataViewer.

I'm sick of BIDS not doing what it is suppose to do. So much time lost in fights with BIDS.

SbastienNunes at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 13
Sbastien Nunes wrote:

DouglasL wrote:

Interrupt execution and display a modal message by using the MessageBox.Show method in the System.Windows.Forms namespace.

here is my code:

MessageBox.Show ("Hello")

In the Input0_ProcessInputRow method.

Not popup shows up during execution.

I have added a DataViewer before the Script Compenent it doesn't stop either on the DataViewer.

I'm sick of BIDS not doing what it is suppose to do. So much time lost in fights with BIDS.

Try using MsgBox("Hello") instead. Note that the window will likely go to the background.

PhilBrammer at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...

SQL Server

Site Classified