Tip #929: Why leading wildcard is not default

Our original wildcard tip has generated some interest and I thought that this very good question from Chase deserves a separate post rather than an inline reply:

I do not understand why this isn’t a native action of searching.

There are multiple reasons why leading wildcard is not a default.

  • I often use “what would SQL Server do” approach when thinking about how Dynamics 365 deals with the records. When you put your SQL Server hat on, you’ll find that leading wildcard search is “expensive” and ineffective.
  • If it was on by default, how would you switch it off? For example, how would you search for customers with the last name “Lee” without also finding “Sleek” or “Branleegate”?
  • Lastly, you already have a leading wildcard when you use Contains operator in Advanced Find

To continue Chase’s question:

How do I setup the search bar to always search as if I have put an asterisk in front of my search? I’m thinking maybe there is an inspect element change I could complete that would do this?

I don’t believe it’s possible without unsupported customizations and it’s better to empower users by teaching them to judiciously use “*” as part of their search term instead.

4 thoughts on “Tip #929: Why leading wildcard is not default

  1. Martin Tölk says:

    Hi George,

    There is an indirect supported way to add a leading Asterix to the quicksearch. It can be done via a PreOperation Plugin.

    The Plugin just Needs to add the wildcard to the ConditionExpression.Value property.

    You can add a “dummy” Field to the view which indicates if the Plugin should modify the query. This will allow you to selectivly enable the Plugin.

    The Plugin needs just to Check if the columnset contains the dummy Field.

    Best regards,

    Martin Tölk

  2. Matt Parks says:

    A better question is to ask “why” users are constantly wanting to search this way. I’ve seen many systems brought to their knees due users who used leading wildcard as their default when entering search criteria. Yes, these were larger systems, but the cumulative effect on the servers can be substantial even on smaller systems.

    Too often, we aren’t willing to challenge our users about how they use the system and work with them to come up with the “right” answer to a problem. Often there is a better place for your coding efforts than just making it easier for them to search inefficiently.

    Matt

  3. MrE says:

    Hi George

    In our CRM Dynamics 2016 on prem, we have the odd behaviour that the system would not retrieve a record from a custom entity.

    We have this entity defined as an entity to search for in the Administration / System Settings and the name field of that record has been set up searchable.

    E.g. the name: 2017_George_Tips_wildcards

    Searching for: 2017_George_Tips_wildcards will bring me up the correct record.
    Searching for: *wildcards will leave me with no results returned.

    (I have tried to remove the underlines_ in the name and did the same searches, with no better results).

    But then I set in Administration / System Settings / Set up Quick Find

    Enable full-text search for Quick Find = Yes to No.

    Guess what happens:

    I can search and find with: *wildcards
    the 2017_George_Tips_wildcards record.

    When I set it back to

    Enable full-text search for Quick Find = Yes

    I can’t find it anymore with *wildcards (I still get it searching with the full name: 2017_George_Tips_wildcards)

    Strange things happening in our system…

    As long as I don’t have any further “reason” which would give us the technical explanation and evidence as to why this cannot work boiled down to the laws of (natural) physics, I am inclined to assume this to be a bug. How exciting! 🙂

  4. […] in search (George Doubinski’s Wildcard Tip of the Day […]

Leave a Reply

Your email address will not be published. Required fields are marked *