Hi,

my approach for dynamic default values is to overwrite the default value in the prompt and data query.

Example:

I create a prompt for "Month key" and added a second data item which contains the key for the current month. If it's not stored in the calendar table, you can use manual SQL in {} or create a simple join. I've changed the content of Month key to an If-Then-Else statement that will return -1 if the months key equals the current month.

On the page I set the default value for the prompt to -1:

Now I just must do a modified filtering on the data query where I also added the current months data item. The filter has to look like:

Finished. Each current month will have the key -1 applied to and as the prompt has this as default value your current month will always be pre-selected.

My sample data runs only until 2013... but it works:
Hope this might be a solution for your issue. The challenge is to get the current month accordingly out of your data.

Hi,

my approach for dynamic default values is to overwrite the default value in the prompt and data query.

Example:

I create a prompt for "Month key" and added a second data item which contains the key for the current month. If it's not stored in the calendar table, you can use manual SQL in {} or create a simple join. I've changed the content of Month key to an If-Then-Else statement that will return -1 if the months key equals the current month.

On the page I set the default value for the prompt to -1:

Now I just must do a modified filtering on the data query where I also added the current months data item. The filter has to look like:

Finished. Each current month will have the key -1 applied to and as the prompt has this as default value your current month will always be pre-selected.

My sample data runs only until 2013... but it works:
Hope this might be a solution for your issue. The challenge is to get the current month accordingly out of your data.

Hi,

my approach for dynamic default values is to overwrite the default value in the prompt and data query.

Example:

I create a prompt for "Month key" and added a second data item which contains the key for the current month. If it's not stored in the calendar table, you can use manual SQL in {} or create a simple join. I've changed the content of Month key to an If-Then-Else statement that will return -1 if the months key equals the current month.

On the page I set the default value for the prompt to -1:

Now I just must do a modified filtering on the data query where I also added the current months data item. The filter has to look like:

Finished. Each current month will have the key -1 applied to and as the prompt has this as default value your current month will always be pre-selected.

My sample data runs only until 2013... but it works:
Hope this might be a solution for your issue. The challenge is to get the current month accordingly out of your data.

Hi,

my approach for dynamic default values is to overwrite the default value in the prompt and data query.

Example:

I create a prompt for "Month key" and added a second data item which contains the key for the current month. If it's not stored in the calendar table, you can use manual SQL in {} or create a simple join. I've changed the content of Month key to an If-Then-Else statement that will return -1 if the months key equals the current month.

On the page I set the default value for the prompt to -1:

Now I just must do a modified filtering on the data query where I also added the current months data item. The filter has to look like:

Finished. Each current month will have the key -1 applied to and as the prompt has this as default value your current month will always be pre-selected.

My sample data runs only until 2013... but it works:
Hope this might be a solution for your issue. The challenge is to get the current month accordingly out of your data.

Hi,

my approach for dynamic default values is to overwrite the default value in the prompt and data query.

Example:

I create a prompt for "Month key" and added a second data item which contains the key for the current month. If it's not stored in the calendar table, you can use manual SQL in {} or create a simple join. I've changed the content of Month key to an If-Then-Else statement that will return -1 if the months key equals the current month.

On the page I set the default value for the prompt to -1:

Now I just must do a modified filtering on the data query where I also added the current months data item. The filter has to look like:

Finished. Each current month will have the key -1 applied to and as the prompt has this as default value your current month will always be pre-selected.

My sample data runs only until 2013... but it works:
Hope this might be a solution for your issue. The challenge is to get the current month accordingly out of your data.

Hi,

my approach for dynamic default values is to overwrite the default value in the prompt and data query.

Example:

I create a prompt for "Month key" and added a second data item which contains the key for the current month. If it's not stored in the calendar table, you can use manual SQL in {} or create a simple join. I've changed the content of Month key to an If-Then-Else statement that will return -1 if the months key equals the current month.

On the page I set the default value for the prompt to -1:

Now I just must do a modified filtering on the data query where I also added the current months data item. The filter has to look like:

Finished. Each current month will have the key -1 applied to and as the prompt has this as default value your current month will always be pre-selected.

My sample data runs only until 2013... but it works:
Hope this might be a solution for your issue. The challenge is to get the current month accordingly out of your data.

Hi,

my approach for dynamic default values is to overwrite the default value in the prompt and data query.

Example:

I create a prompt for "Month key" and added a second data item which contains the key for the current month. If it's not stored in the calendar table, you can use manual SQL in {} or create a simple join. I've changed the content of Month key to an If-Then-Else statement that will return -1 if the months key equals the current month.

On the page I set the default value for the prompt to -1:

Now I just must do a modified filtering on the data query where I also added the current months data item. The filter has to look like:

Finished. Each current month will have the key -1 applied to and as the prompt has this as default value your current month will always be pre-selected.

My sample data runs only until 2013... but it works:
Hope this might be a solution for your issue. The challenge is to get the current month accordingly out of your data.

Hi,

my approach for dynamic default values is to overwrite the default value in the prompt and data query.

Example:

I create a prompt for "Month key" and added a second data item which contains the key for the current month. If it's not stored in the calendar table, you can use manual SQL in {} or create a simple join. I've changed the content of Month key to an If-Then-Else statement that will return -1 if the months key equals the current month.

On the page I set the default value for the prompt to -1:

Now I just must do a modified filtering on the data query where I also added the current months data item. The filter has to look like:

Finished. Each current month will have the key -1 applied to and as the prompt has this as default value your current month will always be pre-selected.

My sample data runs only until 2013... but it works:
Hope this might be a solution for your issue. The challenge is to get the current month accordingly out of your data.

My personal favourite solution for this type of (common) problem, is to have Index values in your Period data source in the data warehouse.

For example, you can add 4 columns to your Period table, with:
DAY_INDEX
WEEK_INDEX
MONTH_INDEX
YEAR_INDEX

These fields contain 0 for current day/week/month/year, -1 for previous, 1 for next, etc.

This allows you to create simple dropdown prompt boxes, that you can order, and display then the common label for the Period, but use the index as parameter value.

The great thing of such solution, is that this makes it very easy to schedule reports on previous/current week or month or day, a very common way to schedule reports in businesses. 
The downside is that currently this solution isn't made possible on pure date selection prompts (via date promptbox) and when you look at the assigned prompts in a scheduled report, Cognos always displays the label, which of course gets updated every week. So if you schedule in January a monthly report and set the report to use -1 as parameter for the month, then the scheduled report will show as prompt parameter in the UI a label with December. 2 months later, the report will run for February, but a user looking at the schedule parameters, will still see "December" (although this is just the incorrect label for the correct setting of -1).

Hope that's clear.
I used to be good at creating Javascript solutions for this kind of problems, but since the Javascripts are now stored not in the report but on the server, it's a bit more work trying to prep such a change. I personally now try to avoid it, as this creates risks thus more time in test/development for future releases. 

Kind regards,
Joeri

My personal favourite solution for this type of (common) problem, is to have Index values in your Period data source in the data warehouse.

For example, you can add 4 columns to your Period table, with:
DAY_INDEX
WEEK_INDEX
MONTH_INDEX
YEAR_INDEX

These fields contain 0 for current day/week/month/year, -1 for previous, 1 for next, etc.

This allows you to create simple dropdown prompt boxes, that you can order, and display then the common label for the Period, but use the index as parameter value.

The great thing of such solution, is that this makes it very easy to schedule reports on previous/current week or month or day, a very common way to schedule reports in businesses. 
The downside is that currently this solution isn't made possible on pure date selection prompts (via date promptbox) and when you look at the assigned prompts in a scheduled report, Cognos always displays the label, which of course gets updated every week. So if you schedule in January a monthly report and set the report to use -1 as parameter for the month, then the scheduled report will show as prompt parameter in the UI a label with December. 2 months later, the report will run for February, but a user looking at the schedule parameters, will still see "December" (although this is just the incorrect label for the correct setting of -1).

Hope that's clear.
I used to be good at creating Javascript solutions for this kind of problems, but since the Javascripts are now stored not in the report but on the server, it's a bit more work trying to prep such a change. I personally now try to avoid it, as this creates risks thus more time in test/development for future releases. 

Kind regards,
Joeri

My personal favourite solution for this type of (common) problem, is to have Index values in your Period data source in the data warehouse.

For example, you can add 4 columns to your Period table, with:
DAY_INDEX
WEEK_INDEX
MONTH_INDEX
YEAR_INDEX

These fields contain 0 for current day/week/month/year, -1 for previous, 1 for next, etc.

This allows you to create simple dropdown prompt boxes, that you can order, and display then the common label for the Period, but use the index as parameter value.

The great thing of such solution, is that this makes it very easy to schedule reports on previous/current week or month or day, a very common way to schedule reports in businesses. 
The downside is that currently this solution isn't made possible on pure date selection prompts (via date promptbox) and when you look at the assigned prompts in a scheduled report, Cognos always displays the label, which of course gets updated every week. So if you schedule in January a monthly report and set the report to use -1 as parameter for the month, then the scheduled report will show as prompt parameter in the UI a label with December. 2 months later, the report will run for February, but a user looking at the schedule parameters, will still see "December" (although this is just the incorrect label for the correct setting of -1).

Hope that's clear.
I used to be good at creating Javascript solutions for this kind of problems, but since the Javascripts are now stored not in the report but on the server, it's a bit more work trying to prep such a change. I personally now try to avoid it, as this creates risks thus more time in test/development for future releases. 

Kind regards,
Joeri

My personal favourite solution for this type of (common) problem, is to have Index values in your Period data source in the data warehouse.

For example, you can add 4 columns to your Period table, with:
DAY_INDEX
WEEK_INDEX
MONTH_INDEX
YEAR_INDEX

These fields contain 0 for current day/week/month/year, -1 for previous, 1 for next, etc.

This allows you to create simple dropdown prompt boxes, that you can order, and display then the common label for the Period, but use the index as parameter value.

The great thing of such solution, is that this makes it very easy to schedule reports on previous/current week or month or day, a very common way to schedule reports in businesses. 
The downside is that currently this solution isn't made possible on pure date selection prompts (via date promptbox) and when you look at the assigned prompts in a scheduled report, Cognos always displays the label, which of course gets updated every week. So if you schedule in January a monthly report and set the report to use -1 as parameter for the month, then the scheduled report will show as prompt parameter in the UI a label with December. 2 months later, the report will run for February, but a user looking at the schedule parameters, will still see "December" (although this is just the incorrect label for the correct setting of -1).

Hope that's clear.
I used to be good at creating Javascript solutions for this kind of problems, but since the Javascripts are now stored not in the report but on the server, it's a bit more work trying to prep such a change. I personally now try to avoid it, as this creates risks thus more time in test/development for future releases. 

Kind regards,
Joeri