At first, I could not get lab data to print with an output condition of:
<<Report Var.Stratum>> = <<SqlRange(_<<Depth>>,_[SAMPLE].[Stratum],_[SAMPLE].[Depth] + [SAMPLE].[Length] / 12_)>>
Yet the sqlrange statement correctly printed "Soil" when placed in the data expression field.
Thanks to a hint from a thread in September, I converted it to this:
<<Report Var.Stratum>> = <<User System Data.GetStratum>>
It worked well.
Are we not allowed to use SQL features inside output conditions? And why does USD help? (The problem is solved, but I'm trying to learn from my mistakes.)
By the way, this is a very slow query. If anyone has any ideas on how to optimize it without forcing the user to type a complicated filter, I'd appreciate it.
You might be able to handle this with an OUTPUT script with user-entered variables for the filter entries - that would combine the ease and speed of a script with the ability to enter the filter parameters as needed.
I'm not sure why the expression works as an output condition when encapsulated in a user system data, but not when it is not. I would try enclosing the entire right side of the "equation" in the expression in parentheses, and see if that does the same thing.
Thanks for the quick response. Parentheses do not accomplish what the user system data does. I assume that gINT has a sequence of operations as it builds a query, and that the output condition is too late in the process to go diving back into the database. Or something like that.