A blog about SQL Server, SSIS, C# and whatever else I happen to be dealing with in my professional life.

Find ramblings

Sunday, January 25, 2009

Variable annoyance

Since I seem to be in a blogging mood today, something to be aware of
within SSIS is that while the data flow task tends to do a very good
job of keeping track of field name changes, the same cannot be said of
renaming variables. For example, if you had a variable, RowCount and
updated that to RowCountActual, you would then need to update all the
places that referenced that variable, like a Row Count data flow task,
the ReadOnly parameter list of a script task, etc.

Nothing major but an annoyance.

Log dagnabit!

The Script Control Flow task is awesome, it really helps SSIS handle
situations that aren't covered by out of the box functionality but
aren't generic enough to warrant a custom task. Some features, in
2005 at least, just don't seem to be as intuitive as one might think.
Events and logging come to mind---not the built in stuff, that's
pretty straight forward but take for example, you want to call this
code.
Dts.Log(errorMessage, 0, Nothing)
where errorMessage is a string you have defined elsewhere. The
package runs and you will look through the rows logged to SQL Server
and nothing. Well sonofagun, why didn't it log? My assumption,
because I don't feel like digging through the documentation, is that
the task correctly raises a log event from the script task but there
is no listener for it and so it drifts off into the ether.

And that
assumption seems to hold water because if I dig through SSS,
Logging... drill down to my actual script task container and then
override the package level logging (greyed out checkmark, to no check,
to a full black check, grab my log provider) what suddenly appears but
an option for ScriptTaskLogEntry. Check _that_ and rerun the package
and now the items logged via Dts.Log will be recorded by the log
provider.

Pictures of the above are available at http://billfellows.blogspot.com/2009/12/log-dagnabit-2.html

Tuesday, January 6, 2009

ASP.NET skins

Where do they go? Why into your bin directory, assuming you
precompile your site.

That is decidedly inconvenient. When I first saw that we were doing
both CSS and themes here, I enjoyed how themes worked with sites.
It's been nearly a year since I was dealing heavily with the look and
feel of the site so some of this is based on foggy recollections.
Fast forward to today. The users request that we make the titles
stand out more so I crack open the css to change it from 8 to 10
point. Oh yeah, that's in the skin file. Browse out to the load
server to tweak it there. Let's see, site, APP_Themes and there's the
css... Sort, resort the folder. Where'd my skin file go? No .skin
file anywhere, which I suppose is good so people can't break the site
by flubbing a file like I was going to do. At any rate, time for me
to head out this evening but your skin file will be in
bin\Theme_<SkinFile>.compiled and bin\App_Theme_<SkinFile>.dll I
didn't get too far with digging through the dll with Reflector but
that can be a task for another day.