Forum Discussion
DirectQuery FoldingWarning "UNSEARCHABLE" despite SQLColAttribute returning SQL_PRED_SEARCHABLE
- 1 month ago
Hi,
Based on the checks you’ve already completed, this does not look like a normal driver metadata issue. Your driver returns SQL_PRED_SEARCHABLE from both SQLColAttribute and SQLGetTypeInfo, and your SQLGetTypeInfo override is being executed, yet the folding engine still classifies the columns as UNSEARCHABLE.
Odbc.DataSource builds its folding behavior from several sources, including driver capabilities, SQL type metadata, SQLGetInfo, and connector overrides. Microsoft documents SQLGetTypeInfo, SqlCapabilities, and related Odbc.DataSource options as supported ways to influence generated SQL and folding behavior. However, the internal logic used by OdbcQuery.Sort and OdbcQuery.Group, including any metadata caching, is not publicly documented.
A few things may help isolate the issue:
Test with a completely new PBIX file after clearing Power BI Desktop’s local cache and trace folders. This can help determine whether stale metadata is being reused.
Change the connector’s data-source path or DSN temporarily so Power BI treats it as a new source and rebuilds its metadata.
Confirm the driver also returns searchable metadata correctly through the ODBC descriptor field corresponding to SQL_DESC_SEARCHABLE, not only the older SQL_COLUMN_SEARCHABLE identifier.
Capture the complete ODBC trace and verify which metadata calls Power BI actually makes before the failure.
Test a minimal table containing only one SQL_INTEGER and one SQL_VARCHAR column, then apply equality filtering, sorting, and grouping separately. Microsoft’s ODBC troubleshooting guidance recommends testing folding operations individually across data types.
Try the same connector and driver with an earlier Power BI Desktop build. If it works there but fails in 2.155.385.0, that would strongly suggest a regression.I don’t see a documented SqlCapabilities or SQLGetInfo option that directly overrides per-column searchability for Sort or Group. SqlCapabilities mainly controls broader SQL grammar and supported operations; it may not replace the type-level searchability value used internally by the folding engine.
Since the trace shows the corrected SQLGetTypeInfo result before the warning, this may be an internal metadata-cache issue or a regression in the current Power BI Desktop ODBC folding implementation. I would recommend creating a minimal reproducible connector and reporting it through Microsoft support or the Power Query SDK repository, including:
The .mez connector
A minimal driver or trace
The failing M query
The full OdbcQuery/FoldingWarning
Results from both the current and an earlier Desktop versionIt would also be useful to know whether a simple equality filter folds successfully and only Table.Sort/Table.Group fail, or whether all predicates are rejected. That distinction could show whether Power BI is treating the column as unsearchable globally or only within specific folding operators.
Hi,
Based on the checks you’ve already completed, this does not look like a normal driver metadata issue. Your driver returns SQL_PRED_SEARCHABLE from both SQLColAttribute and SQLGetTypeInfo, and your SQLGetTypeInfo override is being executed, yet the folding engine still classifies the columns as UNSEARCHABLE.
Odbc.DataSource builds its folding behavior from several sources, including driver capabilities, SQL type metadata, SQLGetInfo, and connector overrides. Microsoft documents SQLGetTypeInfo, SqlCapabilities, and related Odbc.DataSource options as supported ways to influence generated SQL and folding behavior. However, the internal logic used by OdbcQuery.Sort and OdbcQuery.Group, including any metadata caching, is not publicly documented.
A few things may help isolate the issue:
Test with a completely new PBIX file after clearing Power BI Desktop’s local cache and trace folders. This can help determine whether stale metadata is being reused.
Change the connector’s data-source path or DSN temporarily so Power BI treats it as a new source and rebuilds its metadata.
Confirm the driver also returns searchable metadata correctly through the ODBC descriptor field corresponding to SQL_DESC_SEARCHABLE, not only the older SQL_COLUMN_SEARCHABLE identifier.
Capture the complete ODBC trace and verify which metadata calls Power BI actually makes before the failure.
Test a minimal table containing only one SQL_INTEGER and one SQL_VARCHAR column, then apply equality filtering, sorting, and grouping separately. Microsoft’s ODBC troubleshooting guidance recommends testing folding operations individually across data types.
Try the same connector and driver with an earlier Power BI Desktop build. If it works there but fails in 2.155.385.0, that would strongly suggest a regression.
I don’t see a documented SqlCapabilities or SQLGetInfo option that directly overrides per-column searchability for Sort or Group. SqlCapabilities mainly controls broader SQL grammar and supported operations; it may not replace the type-level searchability value used internally by the folding engine.
Since the trace shows the corrected SQLGetTypeInfo result before the warning, this may be an internal metadata-cache issue or a regression in the current Power BI Desktop ODBC folding implementation. I would recommend creating a minimal reproducible connector and reporting it through Microsoft support or the Power Query SDK repository, including:
The .mez connector
A minimal driver or trace
The failing M query
The full OdbcQuery/FoldingWarning
Results from both the current and an earlier Desktop version
It would also be useful to know whether a simple equality filter folds successfully and only Table.Sort/Table.Group fail, or whether all predicates are rejected. That distinction could show whether Power BI is treating the column as unsearchable globally or only within specific folding operators.