Hay todo tipo de cosas que podrían estar pasando.
Primero, Ivan G. tiene razón en que los parámetros de conexión y las opciones SET pueden ser diferentes entre SSMS y su cliente ASP.NET. Eso es algo que vale la pena investigar en Profiler, si tiene acceso a él.
En segundo lugar, si ejecutó su consulta varias veces seguidas en SSMS, es posible que los resultados se almacenen en caché y por eso se ejecuta tan rápido en SSMS. Si se ejecuta lentamente la primera vez que abre SSMS e intenta ejecutarlo, pero luego se acelera, es una señal de que se está almacenando en caché.
En cuanto a por qué agregar una cláusula adicional a una unión podría ralentizar las cosas, es difícil decir por qué sin saber más sobre sus tablas, pero no es imposible que eso lo haya hecho. ¿Hay un índice sobre BATCH_INGR? que incluye tanto FACTORY y INGR_CODE ? Es posible que necesite uno ahora que está incluyendo INGR_CODE en sus condiciones de ingreso.
La mejor manera de averiguarlo es mirar el plan de consulta con y sin el INGR_CODE cláusula y vea cómo difiere. ¿La cifra de costo de una consulta es mayor que la de la otra? ¿Hay escaneos de tablas donde antes no los había? ¿Se ha convertido una búsqueda de índice en un escaneo de índice?
