Yes I have run into this regardless of client language and I consider it a defect in the optimizer.

I wouldn't consider it a defect in the optimizer; it's doing exactly what it's told to do. It cannot convert an nvarchar to varchar -- that's a narrowing conversion. All it can do is convert the other way and lose the ability to use the index. If you think that there is no danger converting an nvarchar that contains only ASCII to varchar then I have about 70+ different collations that say otherwise.

▲

2 hours ago | parent | next [-]

[deleted]

▲

SigmundA 5 hours ago | parent | prev [-]

Can you give an example whats dangerous about converting a nvarchar with only ascii (0-127) then using the index otherwise fallback to a scan?

If we simply went to UTF-8 collation using varchar then this wouldn't be an issue either, which is why you would use varchar in 2026, best of both worlds so to speak.

▲

wvenable 3 hours ago | parent [-]

For a literal/parameter that happens to be ASCII, a person might know it would fit in varchar, but the optimizer has to choose a plan that stays correct in the general case, not just for that one runtime value. By telling SQL server the parameter is a nvarchar value, you're the one telling it that might not be ASCII.

▲

jstrong an hour ago | parent [-]

optimizer can't inspect the value? pretty dumb optimizer, then.

	▲	wvenable an hour ago \| parent [-]
		Running the optimizer for every execution of the same query is... not very optimal.