Connection Managers are key elements of SSIS packages. This article contains a decent overview and links: http://www.mssqltips.com/tip.asp?tip=1147

In an enterprise setting, it’s important to be able to move an SSIS package from Dev, through QA, and into Production without modifications. In the case of Connection Managers, this is accomplished by either creating SSIS configurations, or using the /CONF flag with dtexec on the command line.

Here’s a Brian Knight Vidoe on SSIS Configurations: http://www.jumpstarttv.com/Media.aspx?vid=202

Here’s the MSDN article covering dtexec options: http://msdn.microsoft.com/en-us/library/ms162810(SQL.90).aspx

Eric pointed out that Metadata Issues arise frequently in SSIS dataflow tasks. Fixing them is not particularly elegant. Here’s a link describing the errors you can encounter and the solution: http://followtheheard.blogspot.com/2007/10/ssis-external-metadata-refresh.html

Terry did not disappoint. His reputation for the arcane was reinforced when he mentioned IMEX=1. Apparently, this can be added to Excel connection strings to enforce the interpretation of mixed data within the same columns. Clear as mud? This may help: http://support.microsoft.com/default.aspx?scid=kb;en-us;194124

SSIS Data Flows require a destination, which can be problematic when you’re on a deadline and don’t have control of the database environment. Konesans has a useful free component you can download here: http://www.konesans.com/trashdest.aspx

Script Task! I believe it was Kenneth who mentioned how painful they can be. You’d think a Script Task would lend itself to great Visual Studio debugging integration. Sadly, you’d be wrong. Here’s the MSDN breakdown: http://msdn.microsoft.com/en-us/library/ms140033.aspx

UPDATE a
SET …
FROM targetTable a
JOIN sourceTable b
ON a.keys = b.keys
WHERE binary_checksum( a.col1
, a.col2)
binary_checksum( b.col1
, b.col2)

This is far more efficient than

UPDATE a
SET …
FROM targetTable a
JOIN sourceTable b
ON a.keys = b.keys
WHERE ((a.col1 b.col1)
OR (a.col2 b.col2))

It can be made even more efficient by storing the checksum as a column in your fact/dimension table and indexing it.

BUT… MS does not guarantee that rows that have changed will not product the same checksum. So if you use it, you have to be careful to Test, Test, Test. It is only a small percent of changes where this can occur, but it can.

Further caveat… NULLs in your expression list are ignored. Lets say your list looks something like this

SELECT binary_checksum(1,2,NULL,3)
It will return 291 as the result

Similarly, the following will also produce 291 as the result set…
SELECT binary_checksum(1,NULL,2,3)

Simply casting the columns to a datatype will usually fix this, but i usually coalesce the values with a value unlikely to occur in the dataset. So my update statement above might look somethink like this

DECLARE @ValueIfNullStr varchar
, @ValueIfNullNbr int

SELECT @ValueIfNullStr = ‘#^#@’
, @ValueIfNullNbr = -2000000000

UPDATE a
SET …
FROM targetTable a
JOIN sourceTable b
ON a.keys = b.keys
WHERE binary_checksum( coalesce(a.col1,@ValueIfNullStr)
, coalesce(a.col2,@ValueIfNullNbr))
binary_checksum( coalesce(b.col1,@ValueIfNullStr)
, coalesce(b.col2,@ValueIfNullNbr))

As to the update process, again i think that i would prefer to reverse the order of the process suggested above. The reason here is that I would prefer to not have two rows end dated with high values available simultaneously which would be the case if you first insert the changed row and then update the row that is changing at a later time. If current fact data happens to be loading during this process (which it should not be, but i never trust that that will be the case), I would rather have a row fail to insert into the fact table and handle it as an exception than to have a fact duplicated with no exception raised.

Two additional points…
If the update process is treated as a single transaction, then the concern over two “current” rows goes away, but that means that a larger transaction log must be available.
There might be an argument for a cursor that does both the insert and update or blocking n (TOP (10000) for example) updates and inserts into a transaction block, so that the data consistency is maintained, but the transaction log footprint is minimized.

Let’s be clear that INCOMING fact table rows can be joined to the dimension for range scan to determine _KEY at load time. The rows in the actual fact table should only be joined to the _KEY in the dimension table.