V14.1 Output Sets, loss of relative dates for Output Set Parameters?

Hi Chris,

For your Output Filters, creating code as you suggested could be entered directly into TX_QUERY_ELEMENT_VALUES. Making this type of manual update will not allow you to open the Output Set from the application, but would give you the ability to run the queries and return the data for your Constituents. In v15 we will have the feature available to filter Output Set elements using relative dates from within the application.

Karen

Karen-

Thanks for the replies.

Please see my update in the RAMP support ticket.

Thanks

Chris

Christopher -

Thanks for the workaround.  I found I had to use cast(DateAdd(DAY,1,GetDate()) as date) to avoid conversion errors.

Clarke

Since we have completed the work for relative date filters to be used with Output Set Parameters in our v15 development environment, we are working on releasing it as soon as possible, rather than holding off until v15. We anticipate it being part of the next v14.1 Service Pack, v14.1.3, which is expected to be be released at the beginning of May.

Sweet!

Karen, did this fix get into that service pack?  I skimmed the release notes but did not see it.

Hi Clarke, yes this did get added to the 14.1.3 Service Pack that was released yesterday with the following release note: 
Relative date options are now available when configuring my Output Element Filters

The full release notes for this Service Pack can be found here: www.tessituranetwork.com/.../v14-1_SP

We have loaded service pack 14.1.3 in our Test environment, and were delighted to find relative dates available in the Output Sets. But...

The way our marketing department uses output sets selects information within a date range, like between (DayRunDate +1) and (DayRunDate +8).  It looks like relative dates are not available when you use the "between" operator.  Is there a way around this?  I tried having 2 separate elements pointing to the same data with separate >= and <= statements, and that looks like it failed spectacularly.  

Sandra!

  Thanks for the response.  There were a bunch of Output Sets here that used relative dates and between operators in version 12.5.1.  I am new here, so I would not know if something was the result of a customization.

  I find that in 14.1.3 the GUI will not let me add a second filter referencing the same element.  When I tried adding the same data as a separate element and used <= and >= operators in separate filters, my results had multiple instances of the same constituent.  If I go into TX_QUERY_ELEMENT_VALUES and force the filter to look like it was before the upgrade (SET [value1] = 'DayRunDate +1', [value2] = 'DayRunDate +8', [operator] = 'between'), in the GUI it displays as "With Performance Date between DayRunDate +1 and DayRunDate +8", and the results again have multiple instances of the same constituent (37,000 rows instead of 900).

  My goal is to have this automated via report scheduler with data that does not need massaging each time. It may be time to open a TASK ticket?

Clarke

Clarke Weigle  Just discovering this thread and very thankful for it!

Clarke, have you gotten any update from TASK on this issue?

I created many custom elements in v12 for a scheduled Execute an Output Set solely to use parameters. I can replace them all with standard elements—if I could still use relative start and end dates. Here's hoping!

-- Mike

Hey, Mike!

Version 14.1.3 does have relative start and end dates in Output Sets.  I loaded it in our Test environment (we are still on 14.1.1), but it did not completely solve our issues, so we gave up on this for the time being.  What we are now doing instead is manually setting the parameters on Monday for the Thursday automated reports.

Specifically, I was trying to use scheduled reports with numerous output sets using relative dates with between operators.  As you can see above, no lesser authority than Sandra Ashby said that output sets have never been able to use relative dates with between operators.  This tells me that, somewhere back in time, my employers paid for some customization, so I will try to find records of who did what when.

Clarke