November 20, 2018 at 8:58 am
I have a problem seeing local variables when debugging andSSIS package that is driving me batty. Weuse SQL Server 2008 R2, so I’m still using the VS 2008 shell to develop SSIS packages. When I create a new package, local variables are not present when stopped at a break point during execution.
I’ll set a breakpoint and execute the package. When the breakpoint is hit, the Locals windowinitially shows:
+ Variables
ExecutionDuration
ExecuteStatus
ExecutionResult
When I click the plus sign to expand Variables, the plussign disappears, and no variables are displayed.
When I execute older packages (not created by me) in thesame VS2008 shell, Locals display normally.
The package ProtectionLevel property on all packages isEncryptSensitiveWithUserKey.
The VersionBuild property of the older package, whichdisplays variables properly, is 245. Inthe newer packages I create, it is 342.
Both packages are configured using the Developmentconfiguration, and the debugging options in the Configuration Properties arethe same in both.
Debug settings in the general Options are the same, whichmakes sense as they are running in the same VS 2008 shell.
I am able to view variable by typing them into a Watchwindow, but not having them available in the Locals is very inconvenient.
Does anyone have solution for this?
Thanks,
Mike
.
November 21, 2018 at 12:50 pm
I created a stripped down package and isolated the issue to assigning a Streamwriter to an SSIS object variable in a script task:
Dts.Variables["User::OBJ_LOG_WRITER"].Value = SWriter;
If I comment out this line, variables appear in the Locals window normally at a breakpoint.
This happens in the first task of the package, and the same Streamwriter is used in multiple tasks to append audit information to a text log file by access the object variable and casting it to a Streamwriter. It's also used in an On Error handler to write exception info to the same file.
The alternative would be to instantiate a new Streamwriter in every task the needs to write to the file, which I'd rather not do to work around what *seems* like a bug in VS.
Hopefully I've overlooked something about SSIS variables of type object that's making this happen. Any ideas?
May 1, 2025 at 5:32 pm
What, exactly, would you expect Visual Studio to display for a variable of type "Object" ? Different objects could have any of a number of potentially useful properties, but how should Visual Studio choose? My gut says the developers opted for a less "dangerous" route of not displaying them at all, lest a code bug cause an entirely unnecessary crash...
Steve (aka sgmunson)
Rent Servers for Income (picks and shovels strategy)
Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply
This website stores cookies on your computer.
These cookies are used to improve your website experience and provide more personalized services to you, both on this website and through other media.
To find out more about the cookies we use, see our Privacy Policy