PackageID in Logging Provider

Is there a technical reason (I imagine the real reason is time) that PackageID wasn't included as a Logging Provider column to log? While you can still track this by doing some fun things like event handlers or self-joining, I would think from a usability perspective, you should avoid that altogether by just adding the column.

I added a suggestion here to vote on if anyone else agrees:

http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=e58141d5-859f-4941-a675-cb9352d85575

-- Brian

I'd rather have PackageName!!!

Mind you, one thing I do is dynamically set up the name of my log file using the following expression:

REPLACE(@.[System::PackageName], " ", ".") + (DT_STR, 4, 1252) DATEPART( "yyyy", @.[System::StartTime] ) + RIGHT("0" + (DT_STR, 2, 1252) DATEPART( "mm", @.[System::StartTime] ), 2) + RIGHT("0" + (DT_STR, 4, 1252) DATEPART( "dd", @.[System::StartTime] ), 2) + RIGHT("0" + (DT_STR, 4, 1252) DATEPART( "hh", @.[System::StartTime] ), 2) + RIGHT("0" + (DT_STR, 4, 1252) DATEPART( "mi", @.[System::StartTime] ), 2) + RIGHT("0" + (DT_STR, 4, 1252) DATEPART( "ss", @.[System::StartTime] ), 2) + ".log"

Which gives a package logfilename of MyPackageName20060111142153.log

i.e. Something that contains the package name, and the added benefit that you get a new file for each execution

-Jamie

PackageID and GUIDs in ExecuteSQL task

Am I looking at a potential bug here or do I not understand the feature properly? I have an ExecuteSQL task that inserts into a table for logging and includes the System::PackageID as one of the values. It's stored in my table as a uniqueidentifier. When I set the output variable in Parameter Mappings tab of the Execute SQL task to VarChar, all works great. WHen I set it to GUID as the data type in that tab, it outputs a different GUID than the actual System::PackageID variable.

-- Brian

This is not a bug, although several have thought it was. If you look at the system variable you will notice that even though it looks like a GUID the type of the variable is a string. This is why when you set the SQL task to use a string type it shows the correct value. However, when you set to GUID you don't get the value you expect because the SQL Task doesn't perform conversion for you so the value being placed in your uid field is actually a guid representation of the pointer not that GUID that is pointed to. Currently, if you want to set the GUID into a uid field in SQL I believe you need to use a script task because then you can get the conversion you expect.

HTH,

Matt

PACKAGE START / PACKAGEEND In SSIS

This is a repeat listing - third time - of this problem.

Here's the deal:
If I turn on logging on an SSIS package in Development Studio, when the package executes it will log all the events I choose to the sysdtslog90 table in the MSDB database - INCLUDING the PACKAGESTART and PACKAGEEND events.

When I create my own custom logging, however, those two events ARE NOT being logged, even though I explicitly state in my script I want those two logged. Everything else in the script (OnWarning, OnPreExecute, OnPostExecute, etc.) is being logged.

In my reading, it states that the PACKAGESTART and PACKAGEEND events are defaults and are always logged and cannot be excluded.

If this is the case, can someone explain why they aren't getting logged?

I've seen other people have run across the same issue...This is largely due to technical issues within SSIS. In their rush to release SSIS with SQL Server 2005, Microsoft was unable to get the product fully assed. As a result, SSIS is half-assed at best, and portions of it are barely one quarter assed. You can add this glitch to a collection of SSIS inadequacies, including the ability to import XML but not the ability to export XML, and the ability to add headers to output files but not footers.|||I heard tale that SP2 supposedly clears this up? Is that what you've heard, or can I pretty much just hang it up?

Thanks!|||I haven't heard anything about SP2. Sure would be nice if they someday finished the application they rolled out.|||This is largely due to technical issues within SSIS. In their rush to release SSIS with SQL Server 2005, Microsoft was unable to get the product fully assed. As a result, SSIS is half-assed at best, and portions of it are barely one quarter assed. You can add this glitch to a collection of SSIS inadequacies, including the ability to import XML but not the ability to export XML, and the ability to add headers to output files but not footers.I didn't know that. Gives me a nice "after the fact" sense of smugness that I have so far been able to avoid using the pesky thing entirely.


I heard tale that SP2 supposedly clears this up? Is that what you've heard, or can I pretty much just hang it up?

Got any links? I would like to keep up even if I still come to the conclusion that it is more hassle than it is worth.|||Here ya go:

http://www.microsoft.com/downloads/details.aspx?FamilyId=d07219b2-1e23-49c8-8f0c-63fa18f26d3a&DisplayLang=en|||To any and all interested parties:

I eventually got a response from the Mothsership herself...see below:

I believe the reason the package in the linked thread was working after SP2 is that it was using an Execute Package task, while you are using a script task. The problems you're seeing don't seem to have anything to do with your custom logger - I was able to reproduce the issue using a simple package with a SQL Logger configured.

The PackageStart and PackageEnd events are special, in that they are always fired, regardless of filtering. However, it looks like executing a package through the script task stops the event from actually being propogated up. I'm unable to determine the cause right now, but I will log an internal bug for further investigation.

As a workaround, could you instead fire a custom event from inside the script task, right before you execute the child package?

This response came directly from someone at Microsoft...

The squeaky wheel does indeed get the grease! I guess we can keep our eyes hopefully peeled for a HotFix maybe...or at least getting this addressed in a future Service Pack.|||...I'm unable to determine the cause right now, but I will log an internal bug for further investigation. One step closer to ass-completeness.|||Man...you crack me up seriously!!!!

Kudos, Blindman ;)

Package is getting Parent variables too late?...

Hi,

I am sending variables from package to package by configuration parent packages in each package...
I usually set logging to text files in a certain path that should be received from the parent variable... the strange thing is that if i let the variable in the child package with an incorrect path, my package just through an error even if i am passing the variable from the parent with a correct value...

So... my question is... does my package starts execution without any synch over the parent packages? When are they set? How can i be sure to start my logging with the right parent variable settings?

You can try for example to create a package... add a new variable like "A" and "B" set its value to a default string like "I DONT WANT THIS", add an Execute SQL Task that will record the values of "A" variable to a temporary table...

Then use dtexecui.exe to execute the package and set variable "A" to "THIS IS WHAT I NEED" you will see that in the table will appear one record with the "I DONT WANT THIS" value...

I can't understand this...

Also... if i have 100 variables configured to get values from the parent... is the execution synch or asynch?

Best Regards,

Parent variable configuration is applied to child package at runtime after all other package configuration types are applied and loggers initialized. This is a design decision we have made. To workaround this, you have to use other form of package configuration like XML, SQL Server, etc.|||

So, tell me... even if thats the case... why my parent variables are not set when a certain Execute SQL Task gets actually executed, inserting incorrect values into the table? This is not a very good procedure... How can we make sure to be using the right values in the child package, based on the parent values?

Regards,

|||This should have work. Did you see any error/warning messages about package failed to apply any parent variable configuration?|||

Nop, no errors and no warnings... This is defenitly odd..

Regards

|||

I have had problems with this as well...

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

Package is getting Parent variables too late?...

Hi,

I am sending variables from package to package by configuration parent packages in each package...
I usually set logging to text files in a certain path that should be received from the parent variable... the strange thing is that if i let the variable in the child package with an incorrect path, my package just through an error even if i am passing the variable from the parent with a correct value...

So... my question is... does my package starts execution without any synch over the parent packages? When are they set? How can i be sure to start my logging with the right parent variable settings?

You can try for example to create a package... add a new variable like "A" and "B" set its value to a default string like "I DONT WANT THIS", add an Execute SQL Task that will record the values of "A" variable to a temporary table...

Then use dtexecui.exe to execute the package and set variable "A" to "THIS IS WHAT I NEED" you will see that in the table will appear one record with the "I DONT WANT THIS" value...

I can't understand this...

Also... if i have 100 variables configured to get values from the parent... is the execution synch or asynch?

Best Regards,

Parent variable configuration is applied to child package at runtime after all other package configuration types are applied and loggers initialized. This is a design decision we have made. To workaround this, you have to use other form of package configuration like XML, SQL Server, etc.|||

So, tell me... even if thats the case... why my parent variables are not set when a certain Execute SQL Task gets actually executed, inserting incorrect values into the table? This is not a very good procedure... How can we make sure to be using the right values in the child package, based on the parent values?

Regards,

|||This should have work. Did you see any error/warning messages about package failed to apply any parent variable configuration?|||

Nop, no errors and no warnings... This is defenitly odd..

Regards

|||

I have had problems with this as well...

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

sql

package fails after OnPreValidate (but not in BIDS)

I have all the package logging tickboxes checked but in the log file I only get this:
OnPreValidate,<machinename>,<account>,<packagename>,{7741AD7F-1941-4F4C-AE9D-08068C8856E4},{F6924552-600A-450B-995F-C24AB5C49FC3},6/25/2007 5:21:12 PM,6/25/2007 5:21:12 PM,0,0x,(null)

Then nothing.

The package fails.

When I run it in BIDS I do not get an error.

Anyone know why?If you're not running the package in BIDS, how are you running it? Agent?|||it is running as an all powerful system user|||Right, but is DTEXEC being called from Agent, from a command prompt, or are you using a custom app to run the packages?|||

think this was similar problem to the other issue I was having

we changed the security level to use password, deploy and it works fine now

shame the error couldn't have been more informative

|||

adolf garlic wrote:

think this was similar problem to the other issue I was having

we changed the security level to use password, deploy and it works fine now

shame the error couldn't have been more informative

Well, that's why John and I asked the question that you never answered.... We already knew what the problem was, but needed you to confirm and walk through the problem on your own.