Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Fabric Ideas just got better! New features, better search, and direct team engagement. Learn more

Direct Connect Relationships between multiple sources, resulting in an incorrect query

Here is the general layout of the case for which the issue is arising. We have a simple report based on a data source of two tables: “Supplier” is a simple list of companies and “SupplierAlias” is a list of alternate names they may be known by. An alias may not yet be associated with a supplier (nullable SupplierID) yet if it has turned up in a data feed (part of the purpose of this report). The data source is a sql database and the model is set up for direct query. The report itself is made up of one table of output with columns from both the source tables with a set of slicers where four of the slicers are columns in the table and one is not. Up to this point, everything has been fine. Now if you select as a slicer a value from one of those included in the table, the table visual fails with an invalid column name error. In this case the column is ‘c2’. This happens to be the Alias column from the statement above generated for the unfiltered set and corresponds to the filter I selected. It appears that there is an attempt to make an optimization of some kind by not retrieving the alias column (we know what he value is) and it is dropped from the inner select statement. The problem is that it is NOT dropped from the where clause and causes the error to be thrown. The statement works if either the alias column is returned to the inner select OR the where statement is dropped. Likely just adding the column back to the inner select would keep the logic simpler and would not really inpact overall performance. One thing that is interesting is that if a second item is selected in the slicer, the generated statement is fine again and the table renders. Alternately, if the slicer which not included as a column, SupplierType, is selected in addition to the alias column then the table once again renders fine. Interestingly, the generated code appears to have been run through a different code path than before since the entire outer wrapped query is not gone as well as the previously offending where clause.
Status: Under Review
Comments
chass
Impactful Individual
Hey Tony, Can i talk you out of the BPIX so i can get this filed for you?
fbcideas_migusr
New Member
Status changed to: Under Review