Yellowfin Support Team
Category
Data Sources
Product Version
7.3
How to Provide where clause condition in Sql Query of a View
Completed
Hi Yellow Fin Team,
How can we specify a where clause condition while creating a View.
If you click on Model Tab of a View, will see all the Tables with there relations, Click on Table settings, we can make use of conditions but this is used only for particular Table not for the entire SQL statement.
Scenario : I have Table with status as Priority 1 (5 Records), Priority 2 (5 Records) and some data with Null (5 Records), The data with null value should be updated to Priority 2.
So when i make count while processing report it should show
Priority 1 (5 Records), Priority 2 (10 Records)
But its not possible directly if i use and Calculated fields then also its not able to sum.
Kindly required your help
Thank You.
Files:
Incident.png
The same question 
Hi Sairamreddy,
Unfortunately I am a bit confused as to what you are looking for here. Would you be interested in scheduling a time to screen-share? If so, please let me know what time works best for you. I am on United States Mountain Time.
Regards,
Nathan
Hi Sairamreddy,
Unfortunately I am a bit confused as to what you are looking for here. Would you be interested in scheduling a time to screen-share? If so, please let me know what time works best for you. I am on United States Mountain Time.
Regards,
Nathan
Hi Sairam,
Applying a where clause in the view query depends highly on what you are trying to achieve, what exactly would you like to filter on through this clause?
Typically the best way to apply filters over the entire view is to employ access filters which allow you to limit data by what user/client organization is accessing the data. http://wiki.yellowfin.com.au/display/USER73/Access+Filters
Other than this, your best bet will be to apply these filters at the report level.
From my understanding the "null values" and "where clause" are separate issues, can you please elaborate a bit on this?
Regards,
Nathan
Hi Sairam,
Applying a where clause in the view query depends highly on what you are trying to achieve, what exactly would you like to filter on through this clause?
Typically the best way to apply filters over the entire view is to employ access filters which allow you to limit data by what user/client organization is accessing the data. http://wiki.yellowfin.com.au/display/USER73/Access+Filters
Other than this, your best bet will be to apply these filters at the report level.
From my understanding the "null values" and "where clause" are separate issues, can you please elaborate a bit on this?
Regards,
Nathan
Hi Sairam,
Have you had any luck in resolving this?
One additional thought here is to employ filter groups, which make the application of common filters far simpler than creating them for each report. Please let me know if there is anything I can do to help here.
Regards,
Nathan
Hi Sairam,
Have you had any luck in resolving this?
One additional thought here is to employ filter groups, which make the application of common filters far simpler than creating them for each report. Please let me know if there is anything I can do to help here.
Regards,
Nathan
Hi Sairam,
I am going to set this ticket to closed for now, but if there is anything else I can do to help here, please just let me know and the case will be re-opened!
Regards,
Nathan
Hi Sairam,
I am going to set this ticket to closed for now, but if there is anything else I can do to help here, please just let me know and the case will be re-opened!
Regards,
Nathan
For anyone in 2025 looking for the answer to this. The where clause is in the condition on the primary table. For demonstration purposes, if you build a view and then enter a condition on the first table using drag and drop, the condition will populate in the where clause. If the table is a joined table then the condition stays local to the table join.
Virtual table conditions currently drops to the where clause so try to avoid those.
For anyone in 2025 looking for the answer to this. The where clause is in the condition on the primary table. For demonstration purposes, if you build a view and then enter a condition on the first table using drag and drop, the condition will populate in the where clause. If the table is a joined table then the condition stays local to the table join.
Virtual table conditions currently drops to the where clause so try to avoid those.
Hello Larry
Greetings of the day
Thank you for contacting Yellowfin support. I have noted your response regarding this case. I would like to clarify that when creating a view in Yellowfin, any conditions applied to the primary table will be reflected in the WHERE clause of the SQL statement. Conversely, if conditions are applied to a joined table, they will remain specific to that table join, meaning they will be included in the ON clause of the join.
Understanding this behavior is crucial, as placing conditions in the WHERE clause can alter the nature of the join. For instance, a LEFT JOIN with a condition in the WHERE clause may effectively transform into an INNER JOIN, which might not be the intended result.
I see that you have already submitted a new question ticket to log this as an idea, and our team is currently reviewing it. Additionally, this ticket has been reopened after a considerable time. Please let me know if we can proceed to close this case or if you require any further assistance.
Sincerely,
Siddartha Pathi
Yellowfin Technical Support Engineer
Hello Larry
Greetings of the day
Thank you for contacting Yellowfin support. I have noted your response regarding this case. I would like to clarify that when creating a view in Yellowfin, any conditions applied to the primary table will be reflected in the WHERE clause of the SQL statement. Conversely, if conditions are applied to a joined table, they will remain specific to that table join, meaning they will be included in the ON clause of the join.
Understanding this behavior is crucial, as placing conditions in the WHERE clause can alter the nature of the join. For instance, a LEFT JOIN with a condition in the WHERE clause may effectively transform into an INNER JOIN, which might not be the intended result.
I see that you have already submitted a new question ticket to log this as an idea, and our team is currently reviewing it. Additionally, this ticket has been reopened after a considerable time. Please let me know if we can proceed to close this case or if you require any further assistance.
Sincerely,
Siddartha Pathi
Yellowfin Technical Support Engineer
I think that can’t really apply a global WHERE clause at the View level in Yellowfin, conditions in Table Settings only affect individual tables, not the whole SQL result set. For your scenario, you’ll likely need to handle the NULL → “Priority 2” logic in a calculated field or upstream in the database (e.g., CASE WHEN in SQL) so the aggregation works correctly. @level devil - not a troll game
I think that can’t really apply a global WHERE clause at the View level in Yellowfin, conditions in Table Settings only affect individual tables, not the whole SQL result set. For your scenario, you’ll likely need to handle the NULL → “Priority 2” logic in a calculated field or upstream in the database (e.g., CASE WHEN in SQL) so the aggregation works correctly. @level devil - not a troll game
FawaNews delivers fast live sports scores, fixtures, and HD match streaming online.
FawaNews delivers fast live sports scores, fixtures, and HD match streaming online.
This is definitely a classic Yellowfin data modeling challenge! How we handle and categorize NULL values almost always makes or breaks the final aggregate calculations.
To address your scenario, the most straightforward approach at the SQL level is using a CASE WHEN statement. You would want something like: CASE WHEN status IS NULL THEN 'Priority 2' ELSE status END. Within Yellowfin's View Builder, you can typically apply this logic by creating a Calculated Field. Once that is set up, when you perform your count in the report builder, the Nulls will naturally group together with the Priority 2 records for your sum.
When building BI dashboards, ensuring the accuracy of your underlying data logic is paramount. You want to guarantee that every metric presented is absolutely precise and that your reporting remains reliable and content true.
Honestly, setting up WHERE clauses and data cleansing rules is a lot like installing a good hairfilter in a plumbing system. You need that initial mechanism in place to catch the "impurities" and redirect the messy, unclassified data so that the final stream of information flowing into your reports is clean, clear, and actually useful for decision-making.
I know this is an older thread, but I hope this logic helps out any other developers or analysts who stumble across this same grouping issue!
This is definitely a classic Yellowfin data modeling challenge! How we handle and categorize NULL values almost always makes or breaks the final aggregate calculations.
To address your scenario, the most straightforward approach at the SQL level is using a CASE WHEN statement. You would want something like: CASE WHEN status IS NULL THEN 'Priority 2' ELSE status END. Within Yellowfin's View Builder, you can typically apply this logic by creating a Calculated Field. Once that is set up, when you perform your count in the report builder, the Nulls will naturally group together with the Priority 2 records for your sum.
When building BI dashboards, ensuring the accuracy of your underlying data logic is paramount. You want to guarantee that every metric presented is absolutely precise and that your reporting remains reliable and content true.
Honestly, setting up WHERE clauses and data cleansing rules is a lot like installing a good hairfilter in a plumbing system. You need that initial mechanism in place to catch the "impurities" and redirect the messy, unclassified data so that the final stream of information flowing into your reports is clean, clear, and actually useful for decision-making.
I know this is an older thread, but I hope this logic helps out any other developers or analysts who stumble across this same grouping issue!
Replies have been locked on this page!