|
Comments
|
|
Am I right in the belief that you have to use the Sort function when feeding into a Merge task? if so you could point out that you cant use sort in the SQL task.
|
|
|
I wish I had this in more context. I'm not a SQL Server user and had no clue that a sort transform even existed. It's not part of the formal SQL lanugage, so where does it come from? How is it persistent?
|
|
|
Great as usual, a lot of information in a little time. I knew that you basically shouldn't use a sort transform unless you have a very good reason, and I'm glad you touched on that at the very end.
|
|
|
Pretty neat. Thank you.
|
|
|
I'm not sure I understand why "asynchronous" sorting is less desirable... you didn't really cover that. Certainly, the performance of the sort transform is extremely poor compared to sorting at the sql level. Because of the poor performance, I've also had to rework my flows quite a bit. Are there situations where you had to use a sort? Only place I can think of is you need it sorted one way for an earlier transform and then differently for a later one or maybe because it's not a database source. Typically, I've only attempted a sort when I need to use a merge join, and I found that sorting on the sql side and then setting the IsSorted and SortKey values within the Advanced Transform editor that this is easier.
|
|
|
Holck, not all data originally resides in SQL, so one good case for using SORT is when you're working with data from other/multiple sources
|
|
|
Does the author not know the difference between synchronous and asynchronous?
|
|
|
Simply best tutorial
|
|
|
Good Video, Thank You
|
|
|
terrible speaker...
|
|
|
thank you
|
|
|
Like you say, if you can order it first then that's best. Useful in flat file feeds or xml...
|
|
Chris Manuel on
2/23/2010
excellent!
|
|
Anil Inampudi on
5/26/2010
Good one
|
|
|
Short and sweet, just what it promised and no extra crap, thanks!
|
|
|
good
|