Filters & use of table aliases


Of the two following field filter queries the first one runs fine (widget, dropdowns work as they should), the second one with the alias throws the error “Invalid column name ‘com’.”:

FROM [DashBase].[com].[COUNTY]

FROM [DashBase].[com].[COUNTY] C

Any way around this error when making use of table aliases? With complex queries aliases are indispensable.

v0.28, default MySQL, synced to SQL Server


this is a known issue, you can´t use aliases when you use certain filters:

cheers, Eva


Thank you so much Eva! I was going bonkers trying to figure out what I was doing wrong! For my purposes, for the time being, and for others facing the same issue with Field Filters unable to accommodate Table aliases, I can see only two options:

  1. Creating a View with everything Questions & Dashboards need; key fields, numerical codes, text labels, metrics, and so forth with essentially the same performance latency as a complex query, or
  2. Creating a MOAT (Mother Of All Tables) based on the same which hopefully would return information far more quickly for a more satisfying user experience.

And thanks for pointing out GitHub’s Issues section, I’ll search that as well as this forum in the future!


@mesquest - when I started using Metabase, I did everything using SQL queries. As a BI developer, it was how I felt most comfortable and some of what I was trying to do required many tables.
Then I hit a problem with 0.28 with the multi-select filters not working with SQL queries, so I converted everything to views.
Now, I’m starting to see how well Metabase works with regular tables, so I’m planning to gradually make some of the tables visible and possibly augment with some views when necessary.
It really does do a nice job of managing the joins between tables. The only problem I can see at the moment is that I have a ‘Person’ table that can be used in different ways (carer, client, other), but I can work around that using some very simple views. This will be much more flexible than the approach of one view per question.

I think it’s worth perservering with just tables when possible, even though there will be times when you have to resort to a view.


Oh definitely, using a single or a set of views rather than one per question is the way to go as a table alternative.


Andrew, you captured some “zen of Metabase” very nicely here: :smiley:

Note, I’m reading the excerpt above with ideas on ways to use Metabase shared in the whole Best way to overcome lack of joins thread in mind. I think that is well worth a read if you are coming to Metabase with an “I-need-SQL-to-build-something-powerful” viewpoint.


Thanks! The foreign key field swapping out of a numerical field for a text field label will save me lot’s of unnecessary joins and speed things up for users. That’s a really nice feature that I just discovered just yesterday and I’ll surely use it wherever I can!