Wierd behavior from an Aggregate dataflow task

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Data Warehousing » Integration Services » Wierd behavior from an Aggregate dataflow...

Wierd behavior from an Aggregate dataflow task

Rate Topic

Display Mode

Topic Options

Author

Message

aaron.reese

Posted Thursday, March 14, 2013 3:15 AM

SSC Veteran

Group: General Forum Members
Last Login: Monday, May 13, 2013 7:33 AM
Points: 234, Visits: 441

Hi guys,
I just wanted to know whether anyone else has experienced this and if so what the solution was.
I have a package that as part of a dataflow aggregates data, grouping on 5 columns and summing a sixth. The aggregate is supposed to create a single record which counts the number of lines in the datapipe ( the columns being summed always has a value of 1).

It has never failed in development, which is a 32bit laptop but on occassions in deployment it creates multiple output rows. the data viewer shows no difference in the aggregated columns.

My hypothesis is that before the aggregate I have a derived column task that adds a datetime using getdate() and that for some reason this is calculating different values even though the display value (which is only down to the second) is the same.

I am running BIDS2005 32bit on a Win2008 64bit virtual server when this behaviour is observed but it also happens when running from command line.

Unfortunately the package is permanently running as it uses Konesans file watcher so using the Package Start time variable is not an option for me. Also I dont want to use a script task to set a variable as we have no facility to support the vb script in the organisation (I am a contractor)

Post #1430829

Phil Parkin

Posted Thursday, March 14, 2013 3:56 AM

SSCarpal Tunnel

Group: General Forum Members
Last Login: Today @ 2:25 AM
Points: 4,235, Visits: 9,472

You might be right. Why not try changing your getdate() accuracy to one minute to test your hypothesis?

____________________________________________________________________________________________

Help us to help you. For better, quicker and more focused answers to your questions, consider following the advice in this link:

http://www.sqlservercentral.com/articles/Best+Practices/61537/

If you are asking for help and your post does not contain a question, you should expect responses which do not contain any answers. Put a question mark in there somewhere - it's not rocket science.

Post #1430847

Phil Parkin

Posted Thursday, March 14, 2013 3:57 AM

SSCarpal Tunnel

Group: General Forum Members
Last Login: Today @ 2:25 AM
Points: 4,235, Visits: 9,472

Phil Parkin (3/14/2013)

You might be right. Why not try changing your getdate() accuracy to one minute to test your hypothesis?

Or use MAX(Getdate()) rather than grouping by it.

____________________________________________________________________________________________

Help us to help you. For better, quicker and more focused answers to your questions, consider following the advice in this link:

http://www.sqlservercentral.com/articles/Best+Practices/61537/

If you are asking for help and your post does not contain a question, you should expect responses which do not contain any answers. Put a question mark in there somewhere - it's not rocket science.

Post #1430848

aaron.reese

Posted Thursday, March 14, 2013 7:44 AM

SSC Veteran

Group: General Forum Members
Last Login: Monday, May 13, 2013 7:33 AM
Points: 234, Visits: 441

Phil,

As usual, a simple solution to an annoying quirk of SSIS - Thanks. In this instance I am acutally only interested in the date so I have done a (DT_DBDATE)getdate(). I suppose I might still get a split if someone loads a file at 3 seconds to midnight...

Aaron

Post #1430972

« Prev Topic | Next Topic »

Permissions