Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Wierd behavior from an Aggregate dataflow task Expand / Collapse
Author
Message
Posted Thursday, March 14, 2013 3:15 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Monday, November 17, 2014 2:27 AM
Points: 418, Visits: 652
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
Posted Thursday, March 14, 2013 3:56 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 11:32 AM
Points: 5,257, Visits: 12,185
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.

When you ask a question (and please do ask a question: "My T-SQL does not work" just doesn't cut it), please provide enough information for us to understand its context.
Post #1430847
Posted Thursday, March 14, 2013 3:57 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 11:32 AM
Points: 5,257, Visits: 12,185
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.

When you ask a question (and please do ask a question: "My T-SQL does not work" just doesn't cut it), please provide enough information for us to understand its context.
Post #1430848
Posted Thursday, March 14, 2013 7:44 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Monday, November 17, 2014 2:27 AM
Points: 418, Visits: 652
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 »

Add to briefcase

Permissions Expand / Collapse