I have a simple report grouped by Quarter (with quarterly totals) and
then by Month (with monthly totals).
I would like to give the user the option to select the grouping they
would like to see. If they select a 'Monthly' parameter, is there a way
to ignore the quarterly group?
Currently:
Month,year col1_total col2_total
Month,year col1_total col2_total
Month,year col1_total col2_total
Quarter col1_total col2_total
Month,year col1_total col2_total
Month,year col1_total col2_total
Quarter col1_total col2_total
Report total col1_total col2_total
I would like to not show the "Quarter" line if they select Monthly.
Can this be done with parameters?Michael wrote:
> I have a simple report grouped by Quarter (with quarterly totals) and
> then by Month (with monthly totals).
> I would like to give the user the option to select the grouping they
> would like to see. If they select a 'Monthly' parameter, is there a
> way to ignore the quarterly group?
> Currently:
> Month,year col1_total col2_total
> Month,year col1_total col2_total
> Month,year col1_total col2_total
> Quarter col1_total col2_total
> Month,year col1_total col2_total
> Month,year col1_total col2_total
> Quarter col1_total col2_total
> Report total col1_total col2_total
> I would like to not show the "Quarter" line if they select Monthly.
> Can this be done with parameters?
You can use an expression on the visibility of the group and reference
your parameter. If the parameter equals 'Monthly', set the visibility
to false, else set the visibility to true.
Showing posts with label driven. Show all posts
Showing posts with label driven. Show all posts
Sunday, March 11, 2012
Saturday, February 25, 2012
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.
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.
Subscribe to:
Posts (Atom)