Return to Answer

I had a bit same case in my project. When I investigated how Azure Search works underhood I found that string types all times converted to Contains query in Azure Search. You can see that if taking a look into Search.log for your environment.

The same issue with the StartsWith() function and etc. check this link:

In your case I see some scenarios to resolving this issue:

1. Make a computed field/change type of field year on any numeric type. That can be int. (Equals for numeric types works well)
2. Switch to Solr (it will take 1-day max but will save a lot of time with Search work). Anyway, the azure search will be deprecated in the next version of Sitecore.
3. Use straight requests to Azure Search instead of Sitecore LINQ provider. There exists an Equals function that can be used. (take a lot of time for rewriting and hard to support solution like this)
4. Take a look at the Wildcard() LINQ function that allows using Search Engine syntaxis for field requests. Probably it will help too.

My experience with Azure Search was a nightmare till we didn't switch to Solr Engine in all environments and removed Azure-related things from a project (before we had Azure Search for production and Solr for development). Because they're a lot of limitations.

I had a bit same case in my project. When I investigated how Azure Search works underhood I found that string types all times converted to Contains query in Azure Search. You can see that if taking a look into Search.log for your environment.

The same issue with the StartsWith() function and etc. check this link:

In your case I see some scenarios to resolving this issue:

1. Make a computed field/change type of field year on any numeric type. That can be int. (Equals for numeric types works well)
2. Switch to Solr (it will take 1-day max but will save a lot of time with Search work). Anyway, the azure search will be deprecated in the next version of Sitecore. Check this link.
3. Use straight requests to Azure Search instead of Sitecore LINQ provider. There exists an Equals function that can be used. (take a lot of time for rewriting and hard to support solution like this)
4. Take a look at the Wildcard() LINQ function that allows using Search Engine syntaxis for field requests. Probably it will help too.

My experience with Azure Search was a nightmare till we didn't switch to Solr Engine in all environments and removed Azure-related things from a project (before we had Azure Search for production and Solr for development). Because they're a lot of limitations.

I had a bit same case in my project. When I investigated how Azure Search works underhood I found that string types all times converted to Contains query in Azure Search. You can see that if taking a look into Search.log for your environment.

The same issue with the StartsWith() function and etc. check this link:

In your case I see some scenarios to resolving this issue:

1. Make a computed/change type of field year. That can be int. (Equals for integer types works well)
2. Switch to Solr (it will take 1-day max but will save a lot of time with Search work). Anyway, the azure search will be deprecated in the next version of Sitecore.
3. Use straight requests to Azure Search instead of Sitecore LINQ provider. There exists an Equals function that can be used. (take a lot of time for rewriting and hard to support solution like this)
4. Take a look at the Wildcard() LINQ function that allows using Search Engine syntaxis for field requests. Probably it will help too.

My experience with Azure Search was a nightmare till we didn't switch to Solr Engine in all environments and removed Azure-related things from a project (before we had Azure Search for production and Solr for development). Because they're a lot of limitations.

I had a bit same case in my project. When I investigated how Azure Search works underhood I found that string types all times converted to Contains query in Azure Search. You can see that if taking a look into Search.log for your environment.

The same issue with the StartsWith() function and etc. check this link:

In your case I see some scenarios to resolving this issue:

1. Make a computed field/change type of field year on any numeric type. That can be int. (Equals for numeric types works well)
2. Switch to Solr (it will take 1-day max but will save a lot of time with Search work). Anyway, the azure search will be deprecated in the next version of Sitecore.
3. Use straight requests to Azure Search instead of Sitecore LINQ provider. There exists an Equals function that can be used. (take a lot of time for rewriting and hard to support solution like this)
4. Take a look at the Wildcard() LINQ function that allows using Search Engine syntaxis for field requests. Probably it will help too.

My experience with Azure Search was a nightmare till we didn't switch to Solr Engine in all environments and removed Azure-related things from a project (before we had Azure Search for production and Solr for development). Because they're a lot of limitations.

I had a bit same case in my project. When I investigated how Azure Search works underhood I found that string types all times converted to Contains query in Azure Search. You can see that if taking a look into Search.log for your environment.

The same issue with the StartsWith() function and etc. check this link:

In your case I see some scenarios to resolving this issue:

1. Make a computed/change type of field year. That can be int. (Equals for integer types works well)
2. Switch to Solr (it will take 1-day max but will save a lot of time with Search work). Anyway, the azure search will be deprecated in the next version of Sitecore.
3. Use straight requests to Azure Search instead of Sitecore LINQ provider. There exists an Equals function that can be used. (take a lot of time for rewriting and hard to support solution like this)
4. Take a look at the Wildcard() LINQ function that allows using Search Engine syntaxis for field requests. Probably it will help too.

My experience with Azure Search was a nightmare till we didn't switch to Solr Engine. Because they're a lot of limitations.

I had a bit same case in my project. When I investigated how Azure Search works underhood I found that string types all times converted to Contains query in Azure Search. You can see that if taking a look into Search.log for your environment.

The same issue with the StartsWith() function and etc. check this link:

In your case I see some scenarios to resolving this issue:

1. Make a computed/change type of field year. That can be int. (Equals for integer types works well)
2. Switch to Solr (it will take 1-day max but will save a lot of time with Search work). Anyway, the azure search will be deprecated in the next version of Sitecore.
3. Use straight requests to Azure Search instead of Sitecore LINQ provider. There exists an Equals function that can be used. (take a lot of time for rewriting and hard to support solution like this)
4. Take a look at the Wildcard() LINQ function that allows using Search Engine syntaxis for field requests. Probably it will help too.

My experience with Azure Search was a nightmare till we didn't switch to Solr Engine in all environments and removed Azure-related things from a project (before we had Azure Search for production and Solr for development). Because they're a lot of limitations.