Why is this Definition Query not working?

[ZacharyUhlmann1]

Generally my Definition Query (Pro 3.4) is this:

<Field1> NOT LIKE '%<Value>%' OR <Field2> NOT IN (<Val1>, <Val2>)

Specifically, this is from an NHD Flowline Feature Class and is:

gnis_name NOT LIKE '%Canal%' Or ftype NOT IN (460, 428)

Each component of that compound SQL statement work individually - i.e. either side of the "Or" conditional.  

Note that I tried parenthesizing both components and that does not work either.  

My expected results are features without "Canal" substring in gnis_name and none of ftype 460 or 428.

What's the issue?

[KenBuja]

In this case, you'd want to use AND instead of OR. I think the confusing part for this query is that it uses NOT in conjunction with the OR. That will result in only filtering out the features that have "Canal" and are of ftype of 460 or 428. A feature of ftype 460 will be returned if it doesn't contain "Canal".

To illustrate that, I have a sample dataset where I'm filtering by Region and Field_ID. The original data looks like this

If I apply a query like you have to remove records that don't have 1 in the region name or are not 6563, 6564, or 6565, then the only record removed is the one with PRICO1 and 6564.

If I use AND in that query, then the three records are removed that meet either criteria

[ZacharyUhlmann1 · Accepted solution]

EDIT: The "AND" suggestion in @KenBuja excellent solution works, but the other confounding issue was NULL values for the gnis_name field.  For that reason, I'm accepting this response (mine) as the solution but acknowledging that Ken's contributed half of the solution (thanks!).

Below is original response. 

Here is the updated solution:

(gnis_name NOT LIKE '%Canal%' Or gnis_name IS NULL) And ftype NOT IN (460, 428)

"And" was part of the issue, but also NULL values.

Also of note, I upgraded (under duress) from 3.3.4 to 3.4.0 and as is par for the course upgrading versions in Pro, functionality is behaving in ways that seem unintended.  For example, after applying SQL statement, there is no way to get either the drop down in attribute table selection generator to only show values present in newly-SQL'd feature class.  Nor will the Unique Values symbology reflect the contents of SQL'd attribute table.  For instance, even though ftype 460 and 428 are removed no longer present in attribute table post SQL application, they still are present in dropdown, and even after recalculating the unique symbology, they still show in table of contents, legend, etc.

But to your solution, the logic makes sense now.  Always trips me up.

thanks.