Can anyone help me understand a question re Data Driven Query Tasks?

I was wondering if anyone could possibly confirm for me that I
understand the comcept of binding tables in DDQ's, as I admit I'm
slightly (but not totally) .
I have 2 DDQ's, one to transfer data from some columns of my one source
file (a csv) into 'table 1', and another DDQ to transfer other columns
from the same csv into a separate table, 'table 2'.
Now, the first DDQ is OK. However, in the second DDQ, my update query
refers to a source csv column (in the query's WHERE clause) that
doesn't have a direct corresponding column in table 2. (Table 2 here is
my binding table.)
In order to 'reference' the source column, I'm having to basically map
that source column to a column in the binding 'version' of table 2 (a
column that I'm not 'using' in this DDQ), so that I can use it in the
Parameters list. In other words, I'm mapping it to a column of a
different name that has no real relevance to it, but is redundant for
this particular query/transformation.
Is this the correct way to do this? i.e. although the binding table
used is originally a real destination table, in its binding 'capacity'
it's only actually used as a way of mapping and referencing source
columns, and in actual fact bears no relevance to any data
transformations (i.e. this 'mapping' doesn't actually alter data in the
destination column - only my QUERY can does this, in which the
destination table itself is used as a real query destination table,
rather than as the binding table).
I'd be grateful if someone could set my mind at ease and clarify that
I've got this right in my head!
Thanks folks.> Is this the correct way to do this? i.e. although the binding table
> used is originally a real destination table, in its binding 'capacity'
> it's only actually used as a way of mapping and referencing source
> columns, and in actual fact bears no relevance to any data
> transformations (i.e. this 'mapping' doesn't actually alter data in the
> destination column - only my QUERY can does this, in which the
> destination table itself is used as a real query destination table,
> rather than as the binding table).
Your understanding is basically correct. The main purpose of the binding
table is to facilitate parameter definition and mapping. For row source
each row, data are transformed to the binding table columns (no data
persistence) and binding table columns are mapped to parameters that are
used in your queries (which do all the work).
Normally the destination table can be used as the binding table but this is
obviously not possible in your case because the destination table doesn't
contain all the necessary columns (parameters). If you use unrelated
columns, be sure to add some comments to your package to aid subsequent
maintenance. You might consider creating a third table strictly for the
binding table role.
Hope this helps.
Dan Guzman
SQL Server MVP
<champ.supernova@.gmail.com> wrote in message
news:1145875189.323814.224810@.t31g2000cwb.googlegroups.com...
>I was wondering if anyone could possibly confirm for me that I
> understand the comcept of binding tables in DDQ's, as I admit I'm
> slightly (but not totally) .
> I have 2 DDQ's, one to transfer data from some columns of my one source
> file (a csv) into 'table 1', and another DDQ to transfer other columns
> from the same csv into a separate table, 'table 2'.
> Now, the first DDQ is OK. However, in the second DDQ, my update query
> refers to a source csv column (in the query's WHERE clause) that
> doesn't have a direct corresponding column in table 2. (Table 2 here is
> my binding table.)
> In order to 'reference' the source column, I'm having to basically map
> that source column to a column in the binding 'version' of table 2 (a
> column that I'm not 'using' in this DDQ), so that I can use it in the
> Parameters list. In other words, I'm mapping it to a column of a
> different name that has no real relevance to it, but is redundant for
> this particular query/transformation.
> Is this the correct way to do this? i.e. although the binding table
> used is originally a real destination table, in its binding 'capacity'
> it's only actually used as a way of mapping and referencing source
> columns, and in actual fact bears no relevance to any data
> transformations (i.e. this 'mapping' doesn't actually alter data in the
> destination column - only my QUERY can does this, in which the
> destination table itself is used as a real query destination table,
> rather than as the binding table).
> I'd be grateful if someone could set my mind at ease and clarify that
> I've got this right in my head!
> Thanks folks.
>|||Thanks Dan, will certainly comment it to be on the safe side.