Bridge parameter and default tokens

#1

I am using a bridge parameter (which will be bound to a calendar range filter, but I am not here yet) and I try to test it.

It is a RangeMember, using the usual Y > M > D hierarchy.

This is my script, casting the lower bound to a string, formatted as a date:

var lower=$input$.Resolve().LowerBoundaryValue;
if (lower == null) {
return “1900-01-01”
} else {
DateTime v = lower.MemberTime;
return v.ToString(“yyyy-MM-dd”);
}

I can test this script from inside the data cube.
If I select myself a date (lower bound), my script returns the date. Good.
If I select a token (eg. last 30 days) I get “1900-01-01”, so the lower bound is always found as null (the upper one as well).

I thought that using .Resolve() was enough.

What am I doing wrong?
(on a side note, I am using Dundas 6.0.1, released yesterday)

Changing the first line to explicitly cast makes no difference:

var lower=((RangeMemberValue)$input$).Resolve().LowerBoundaryValue;

Thanks,

#2

The following script seems to work for me.

var resolved = (RangeMemberValue) $input$.Resolve();

if (resolved == null) {
  return "1900-01-01";
} else {
  var lower = resolved.LowerBoundaryValue;
  var v = lower.MemberTime;
  return v.ToString("yyyy-MM-dd");
}

Here you can see the token setup and the test value correctly displaying.

image
image.png846×1064 47.5 KB

Is everything else on my end set up like yours? If so, then the script should indeed work for you.

#3

Thanks Cristian. Which version of Dundas BI are you using? I am on the latest (6.0.1.1000).

Your script cut&pasted gives me the error:

Runtime error Object reference not set to an instance of an object. Line: 7 Column: 17

Which is the dot at resolved.LowerBoundaryValue.

But that’s interesting. In short:

  • resolved is not null (as expected)
  • resolved.LowerBoundaryValue is null (and that’s the issue)

Once more, this is only when I use a token (like last 30 days in your screenshot). When I manually select a date, I have the expected output.

#4

It feels like a regression to me, I a pretty sure it worked fine in version 6.0.0.

#5

Hi,
I need to change “Value Type” of Bridge Parameter,
I can delete the existing one and create a new one, is there a more friendly way?

Thanks!

#6

You do have to delete the bridge parameter and re-create it if you want to change the value type. The reason for this is because very different data types will potentially have completely different scripts powering them. Since there isn’t a lot of re-use potential you do have a re-create from scratch if you are changing data types.

#7

Was there ever a resolution to this issue? I still seem to be running into Calendar bridge parameter token issues that are the same as the original poster. This is on the newest Dundas version too.

#8

We do have a couple of feature requests pending at this time that would allow you to potentially resolve this issue. The feature requests in question are 79292 and 80074. You have been added to both and as such, will be notified when they are fixed and released.