We use RCP to only show columns that have transforms. That way it makes it easier to view. The other columns have not changes and are just passing thru. Much cleaner.
RCP can be confusing at first, since you can do manipulations on columns that don't seem to exist. Along the same lines, you can get confusing warnings in joins when a column is marked as "duplicate" because it is coming from RCP.
In terms of execution and compile times there is no difference.
To answer the question as originally asked, IMHO I would never simply turn it on at the Project level unless you had an expert developer team all of whom were very comfortable with it.
-craig
"You can never have too many knives" -- Logan Nine Fingers
The best reason I've seen for RCP is when you have a set of functions (stage types) that you want to use to process a vast set of tables, each that has a different structure ....especially in cases where you don't need "really specific" transformations on certain column names...... Entire generic jobs are written that have no columns at all...... These scenarios may be rare, but it becomes a very powerful option to have a job that works against nearly "any" table.
I've also used it shops with very large structures (for example a record with hundreds and hundreds of columns) where only a few columns needed to be worked on, but all columns needed to be transmitted along to the end result.
I only enable it on a per-job basis - it can cause a lot of problems otherwise.
</a>
