YAPS on Filters in an RDL: What’s not to Like?

Last week I wrote about my inability to use the "Like" filter on a table in an RDL.  I wasn't able to use "Like" and devised another solution that uses "Equals" instead.  I went on to show how you could make it more re-usable, etc, but asked whether readers had any ideas.

I'm happy to say that one of you did. Abdallah Elhawary wrote in to explain that the wildcard character is actually supposed to be a "*" rather than the standard SQL ones.  I'm still scratching my head over where this is written in the docs, because I swear I've looked.

At any rate it does work; you can do this successfully:

… so "Like" really does work.

Or… we could talk some more.

(That's a quote from Serenity — I'm seriously behind quota. )

If you want to write something that ports to multiple reports more easily, and isolates the set of fields to be compared for each report table, you're still going to write a function something like what I showed in the other post.

What's more, it turns out that while my weird workaround provides a way to handle case-sensitivity in the comparison at the whim of the user, the Like filter is not going to give you the same ability. 

In fact, looks to me (not testing!) as though if the database does a case-insensitive comparison, that's what you get, and if the database is case-sensitive, that's what you get.

Since this probably means you're doing the filter before dragging the data, it's probably more performant (note again: I haven't tested this assumption about how it works!). So sometimes Like is just what the doctor ordered.

Other times, though… and here I'll quote from another great movie… you just gotta learn to be more flexible. When you're searching free-form text, the user wants to specify case-sensitivity, whole word only, etc.  And with just a little extra work, we can do those things.

Isn't it wonderful that we have both choices?

Thanks again to Abdallah; I have always been a believer in Love but he has restored my faith in Like.