Search bar that isn't capital sensitive

I can’t seem to find a way of making a search bar that isn’t capital sensitive. I’m trying to search for a name in my database, but the names are capitalised. I’m currently using a basic input box, and a repeating group filled with a list of entries, whose names contains the input box’s value. Is there a way to make this not capital-sensitive? Seems like a simple issue for me and there’s probably an obvious solution I’m not seeing. Any help with this would be great, thanks! :slight_smile:

Try fuzzy search

Thanks @loulouaying1204 for the suggestion, but I should’ve mentioned that I have already tried this - it was too slow for my relatively large database.

If you have large volume of data you can try algolia

If you know in advance that all entires in the database are uppercase, you can use the “:uppercase” operator to convert the search term before evaluating it in your filters.

Why don’t you save everything in the small case in your database and while matching with input data, make it too small case using (:smallcase) operator.

My approach to this is to create a variable attached to the input that is updated on input change. The value is then set to its lowercase version. On the “do search for” you can then filter advanced based on this variable that is “lower case” of your input and a lowercase filter that you can apply to the data field of the “thing”. At the end this works great.

I’ve run into this exact issue.

I have a “search string” for every object in the database that is kept updated using database triggers for all objects. This string is all lowercase and includes all the values I’d like objects to be searchable by.

I think just search for objects using this single field and lowercase the input.

Search is lightning fast even with large lists.

1 Like

Thank you @loulouaying1204 , @sam.morgan , @ankur1 , @it16 , @aj11 for your suggestions! I will try these all out :smiley:

1 Like

Do you have a “thing” that is a tupple of (“lower case string”, “unique_id” , “object type”), or do you add a “lower case string” field to the thing? What if you have many fields to search for? Do you create several lowercase fields? Triggers on data tables are to be used, in my view, as a last resource… On the long run, it will bite you…

How would it bite you? As long as you stay organized and label everything I don’t see how it would ever be an issue.

I use one search string field for 6 different elements of data related to the thing. My search is for contacts, so I have first name, last name, phone, email, organization, address. I put a special character between each element that is not on a regular keyboard to keep them separated without adding spaces (which can throw off search).

If you want users to be able to search for any of the elements in one search bar, then you’ll need everything in one search string, otherwise you’ll have to use multiple simultaneous searches and add the lists together before displaying, which is much much slower.

Just to cover all the ground here (and for newbies running across this post)… while the “contains” operator is case sensitive, the “contains keywords” operator isn’t. And the “searchbox” isn’t case sensitive either.

I prefer “contains keywords” anyway because even when ignoring the case sensitive issue, “contains” can be restrictive since word order needs to match 100%. Additionally, I use the “searchbox” rather than a “contains keywords” in situations where the user is searching for a specific entry.

Why the “contains” operator is case sensitive, who knows. It’s been a known issue for some time.

1 Like

Triggers on data tables will bite you because of the extra handling. Every change on the thing will make a validation and, if needed, an update on the database. That, at least, doubles the effort on the i/o of data to the database.

One unique field for several fields is smart. I would only change from being updated during a trigger to an explicit change on the relevant fields.

This topic was automatically closed after 70 days. New replies are no longer allowed.