If you’ve ever been coached or trained in public speaking, you’ve probably been made painfully aware of your use of the dreaded filler words—words you say almost automatically when speaking and nervous. Everyone has their own flavor of it, but for me, it’s the word “like.” If I’m really nervous, I can end up sounding like Moon Unit Zappa in her single Valley Girl. (Millennials, ask your parents. Gen Z, ask your grandparents.)

But the word “like” gets a bad rap and in some uses is fine and perfectly acceptable, like making a comparison or at the beginning of a list talking about the uses of like. Today, though, I’m talking about like in the context of new features added to Synergy/DE in version 11. Which introduces the new system-supplied class Select.Where.Like.

If you aren’t familiar with the Select class in Synergy, where have you been? We’ve been harping on about this thing, like, forever. It’s a wonderful feature in the language for reading data in a SQL-like way. Well, the Select class now has even more functionality with the addition of the Like statement, allowing you to filter your alpha results based on a matching pattern. It’s similar to Where.Contains in that you can do the equivalent of Where.Contains with Where.Like, plus so much more. A Where.Contains is a Where.Like that has a “%” sign in the front and back, telling it to search the results for that string of characters anywhere in the field.

How does Select.Where.Like work?

Using the above wildcards, you can build your Where statement to look for a pattern inside a record field. For example, say you have a city address in the form CityName, ST(ate). Now let’s say you want all results from entries from CA where the city starts with “SAN”. What would this look like?

Where.Like(city_name,"San%,CA%")

Breaking this down, the first three characters are “San”, then there are one or more characters between “San” and our next part “,CA”, which can have one or more characters after it. This query should return results like San Francisco, San Diego, Santa Monica, and San Jose.

Note that you can do a Where.Like that is not case sensitive with NoCaseWhere.Like. The above statement wouldn’t find a city if “san” was in the body of the city name, like Pleasanton, CA. This is most helpful if your data is not uniform or consistent (like sometimes the state is ca or cA). To get the most use out of Where.Like, you should be familiar with your dataset and how information is entered and modified.

Getting an idea how this works

Let’s try something a little tougher. Let’s say you have data that contains postal codes, but the postal codes can be from different countries. Now you could combine your Where.Like with an AND to a field that has a country, but you could also handle it all within the Where.Like. For instance, let’s say the data has postal codes from three different countries: United States, United Kingdom, and Sweden. An example of each one would be

US: 99999
Sweden: 999 999
UK: varies but most commonly AA9 9AA

where 9 is a number and A is a letter.

If we wanted to be completely explicit, we could use these Where.Like statements:

US: [0-9][0-9][0-9][0-9][0-9] 
Sweden: [0-9][0-9][0-9] [0-9][0-9][0-9]
UK: [A-Z][A-Z][0-9] [0-9][A-Z][A-Z]

This is a manual way to handle it, but maybe we can do it with less. If we want only US and Sweden, we can use the fact that UK postal codes have letters to our advantage and go with a simple

US & Sweden: [^A-Z]%

This essentially equates to any postal code that doesn’t begin with a letter, which works for our simplified version of these countries’ postal codes. The opposite, [A-Z]%, also works if you want UK only.

If we want to do Sweden and the UK, we note that both contain a space in their postal codes, so

UK & Sweden: %[ ]%

This includes any postal code with a space in it. Now this is tricky, as these could be Synergy alpha types, and there might be trailing spaces at the end. To fix this scenario, we use a wildcard to say there is a number or letter after the space:

UK & Sweden: %[ ][0-9]%

This means that we are looking for a space with a number immediately following. However, unlike the last example, we can’t use the opposite of this to get US only, because %[^ ][^0-9]% actually works for all three countries if there are trailing spaces; a letter or number at the end followed by a non-numeric character works. For example, a UK postal code ending in “G” with trailing spaces satisfies this condition.

What’s unique about US postal codes, though, is that there are a series of four numbers in a row, and they have fewer total characters than the other two. Therefore, %[0-9][0-9][0-9][0-9]% would work, as would _ _ _ _ _  % (i.e., five wildcard spaces followed by a literal “ ”), as there would be a space afterwards if this were an alpha field, whereas it would be a numeric or alpha character in the UK or Swedish postal codes. Of course, this would be quite different in practice, because your searches would look more like “98_ [0-9]%” if you were looking for Swedish postal codes starting with 98. But the purpose here is to get you thinking with wildcards. This new feature has a lot of potential to optimize searches as it does when used inside of SQL. Be sure to try it out now in Synergy 11 and read more about this feature in our online documentation.