New Topic

Community Topic Problem Report Builder

Lesley Goggin

EMEA SD Team

Chris McCarthy

Yellowfin Support Team

Assigned

Category Report Builder

Product Version 7.2

Filter Values List Shows A Wrong Date

Tal Mickel shared this problem ago

Resolved

We've set a date filter to show data between January and December of 2017.

Yellowfin shows this in the filter values list -

/8679f952b3ba00559a98742e0ad4439d

the generated SQL shows the following -

/0bcac79c3344916623104e0b48902cf8

The same problem 0

Replies (6)

Guest ●

Hi Tal,

could you please tell me the following things:

1) how the "Date (Volume)" column is set up. For example, I can see that it is yyyy-MM, but is this done at the report or view level? Is it done by changing the formatting, or by using a data function? Or is it done by Freehand SQL in a virtual table, or calculated field?

2) how are the filter values (2017-01 And 2018-12) created.

regards,

David

Reply URL

Tal Mickel ●

Hey David ! Dor here

1) the "Date (Volume)" is actually "Month Date (Volume)" and its set up like that - (YYYY-MM-DD) 2017-12-01. The formatting makes it YYYY-MM - 2017-12.

2) through the filter side-bar, we choose the field, then press on Value -> Define Value - and then choose a date range from the calendar that pops up.

URL

Guest ●

Hi Dor,

thanks for the information, I have set up the same sort of report over here - I used a SQL Server Date type (i.e. not Timestamp) and then formatted it in Yellowfin to be yyyy-MM, but unfortunately the filter values list is behaving correctly for me:

/sPiCABKWCnXXkAAAAASUVORK5CYIIA

I wonder if the issue is to do with a particular build of Yellowfin 7.2? I am using 20170714, could you please tell me which build you are on and then I will use the same and hopefully replicate the issue.

By the way, is there always an issue with the 2nd date in the filter values list? Or is it only when the value is 20171231?

regards,

David

Reply URL

Tal Mickel ●

Hey Dave! Dor here

We're using 7.2 20170602

Regarding your question - I didn't try to make the second date first just to check if its only the second. Regarding whether its the value 20171231 or not - I'll check and let you know

Thanks!

Dor & Tal

URL

Guest ●

Hi Dor,

bad news I'm afraid...I tried to replicate the issue with 7.2 20170602 but was not successful. I have attached a short video of my failure ("Filter_values_list.mp4"), if you see that I am doing something wrong in it could you please let me know.

And if it turns out that my replication steps are indeed correct then we've got to work out how to proceed from here - I know it can be difficult to send across to us backups of both your Yellowfin database and your data source, so how about this for an idea: If you can create a report with the issue when using the Yellowfin config db as the data source then all you'll have to do is to give us a dump of your Yellowfin database for us to be able to reproduce the issue over here. What do you think?

regards,

David

Files:

URL

Dor David Makmal ●

Hey David !

Ryan and Mike has our YF DB and an SQL schema script

will that help you with this matter ?

BTW - in 7.4 - did it get fixed ?

URL

Guest ●

Hi Dor,

that's a very good idea, I'm passing this ticket along to Mike in the USA - hopefully he'll be able to replicate the issue seeing as he's got your database and DW.

Regarding whether it got fixed in 7.4...that's a difficult one to answer because I don't know if it was broken in 7.4 in the first place. I have tried to replicate the issue in 7.4 and I was not able to (I have attached a short video of my failure) - but then again, I also wasn't able to replicate it in 7.2 either, so I don't think it is very good proof that it has been fixed in 7.4!

I guess the best proof will be if Mike can replicate the issue in 7.2, then he could upgrade his instance to 7.4 and that way he will know for sure whether it has been fixed in it or not.

regards,

David

Files:

URL

Mike Sheehan ●

Hi Dor,

I found the corresponding date filter in your 7.2 build 20170602 instance, but the SQL statements are being generated as expected:

500380612e6fa4a5b2bfe2e1852c3db1

Also works when I filter by 2017-01 And 2018-12:

42295ed5d374174e95dbb69a889402ed

Do you think the data has been changed since the November '17 upload?

Let me know if the following are still a match. Here are the settings in the Column Formatting section:

f20e24ae2197f9ff4fed7d09a4411c9d

And for the view:

9a6b96ee2ce73ae6c8a0c21983df1c37

I look forward to your response.

Regards,

Mike

Reply URL

Dor David Makmal ●

Hey Mike !

I think there's a misunderstanding

The SQL is good. The showed value is wrong, it shows 1 year in addition to what we've set.

Its confusing our users.

And I can see it happened in your first screenshot

you filtered 1957-12, yet you got 1958-12 showed.

URL

Mike Sheehan ●

Hi Dor,

Whoops! Good catch! Upon further investigation, and testing in both 7.2 and 7.4, what happens is: If I set Date Between 01/06/50 - 12/31/1957, for example, my results are correct, which is the good news. They are showing all my data values between those dates, and the SQL code is correct:

f42767c9043ca53af8fb62a13bbb167f

The part that is incorrect is that the Display Filter Values description, which is inexplicably showing 1958-12. The other observation/somewhat good news is that this doesn't appear to be happening when you choose any other date other than the last two days of the year, which leads me to believe this has something to do with TimeZone. Perhaps it's pushing up to the next year. Though of course staying as "12" for MM value would be incorrect regardless.

Nevertheless, as can be seen, this has been replicated so I am going ahead and raising this as a defect for the dev team to take a look at. In my second example on my previous reply, there was no data set to be filtered, so perhaps it's the way the filtering is interacting when there's data that's causing this to happen. Either way, I'll go ahead and forward my replication steps to the dev team. Any updates regarding this matter will be posted here.

Regards,

Mike

URL

Dor David Makmal ●

Awesome, Mike !

Thank you so much.

URL

Mike Sheehan ●

Hi Dor,

You are welcome.

Regards,

Mike

URL

Dor David Makmal ●

Hey Mike !

Any update for this one ? :)

URL

Mike Sheehan ●

Hi Dor,

Unfortunately, no updates on this yet. We had another client report this behavior but in their case we made it able to work by changing the formatting to 'MMM-YY' from 'mmm-YY', but that doesn't seem to be applicable to your case as yours was already set to all caps. Though of course this still could have something to do with formatting at the report level, i.e., I wouldn't be surprised if you changed the formatting if it displayed properly. Of course, it's still a bug and should be investigated, just still awaiting updates regarding it. The dev team's been hammering away through internal tasks so I'm hoping we'll hear something soon.

Regards,

Mike

Reply URL

Mike Sheehan ●

Hi Dor,

Does this issue still occur for you now that you've upgraded to 7.4?

Thanks,

Mike

Reply URL

Chris McCarthy ●

Hi guys,

We're just closing this one off as it's for version 7.2, but let me know if there's anything else you want to discuss around this issue.

Kind regards,

Chris

Reply URL