I am using the follwing expression (DT_WSTR,1000)@(System::PackageName)+"package failed on"+(DT_WSTR,1000)GetDate() Now I have a user defined function called PUser.ZoneDate. When i replace the GetDate() function with either Puser.ZoneDate or ZoneDate or[Puser].[ZoneDate] and try to evaluate the expression i get the followng error: The Function TimeZoneGetDate is not recognized. It might contain invalid elements or it might not be well formed. Can anybody suggest where I am going wrong

Unfortunately you cannnot use user defined functions in SSIS expressionsss. This is really disappointing because the SSIS expression library is really poor.

You will have to use a Script Task (or Script Component if in the Data Flow Task) for that. Then you can use the .net timezone class. Here is an other forum thread with a timezone question: http://social.msdn.microsoft.com/Forums/en-US/sqlintegrationservices/thread/76a58fee-471c-436d-bea4-c4698df5a4cf Please mark the post as answered if it answers your question | My SSIS Blog: http://microsoft-ssis.blogspot.com

In general I would advise against using Script Tas, except there is no other option. The main disadvantage is imho that it is not reusable, the only way to reuse it is copy & paste the code. In case you have 100's of packages and need to change the script... lots of fun. In your case there might be a better option. As far as I understood you are going to implement some kind of error handling. Well, you could encapsulate the "logic" for building an error message and save it to a table in a stored proc. Just call the proc from Execute SQL task with appropriate parameters and let it do the rest. Ifthere will be a requirement to change the error handling functionality, then you'll need to adjust only this one proc and not all the 100 scripts. Hope this helps

Reusabiliy is no problem with a Script Task/Component. You can create a custom assembly(library) with your own functions and use that in all Script. And if you have real good .net skills (and some time) you could even write a custom component: http://ssisctc.codeplex.com/ The SQL or .Net solution... It's just a matter of taste. Please mark the post as answered if it answers your question | My SSIS Blog: http://microsoft-ssis.blogspot.com

Well, you could use an external assembly... but in allmost all projects i was involved in as consultant it was done the way you suggested, just use the script task to wright some custom code. Mabe because it is so easy? :) In order to use a custom assembly you need to sign, depploy it to GAC and .NET Framework folder, it's harder to debug and to fix and you need to redeploy it etc. From a BI Developer I would expect strong T-SQL skills not strong .NET development skills.

I think you have two kind of SSIS developers (at least that's what I see for my colleagues): 1) The former DBA/T-SQL developer who got bored with writing T-SQL all day and switched to BI (he/she will probably go for the T-SQL function). 2) The former .net developer who got bored with writing .Net all day and switched to BI (he/she will probably go for the .Net method). In my opinion there is no good or bad. If you want to accomplish re-usability, you have to do it right for both T-SQL and .Net. It's now up to Yuktah to determine the best solution for him :-)Please mark the post as answered if it answers your question | My SSIS Blog: http://microsoft-ssis.blogspot.com

It shoudn't be a matter of your background imho. It is a dicision that has an impact on the quality of solution design, to make use of reusable 'components' or to go with custom code in script task that often will lead to copy&paste 'reusability'. Using a custom assembly for the 'problem' we're discussing here is imho just a work-around for the lack of reusability in script task. In my opinion you will more often deal with databases and sql in the area of BI then with .net development regardles of what your background is. But sure, let Yuktah choose the best solution for him :-)