Il peut se passer toutes sortes de choses.
Tout d'abord, Ivan G. a raison de dire que les paramètres de connexion et les options SET peuvent être différents entre SSMS et votre client ASP.NET. C'est quelque chose qui vaut la peine d'être examiné dans Profiler, si vous y avez accès.
Deuxièmement, si vous avez exécuté votre requête plusieurs fois de suite dans SSMS, il est possible que les résultats soient mis en cache et c'est pourquoi il s'exécute si rapidement dans SSMS. S'il s'exécute lentement la première fois que vous ouvrez SSMS et essayez de l'exécuter, mais qu'il s'accélère ensuite, c'est un signe qu'il y a une mise en cache en cours.
Quant à savoir pourquoi l'ajout d'une clause supplémentaire à une jointure pourrait ralentir les choses, il est difficile de dire pourquoi sans en savoir plus sur vos tables, mais il n'est pas impossible que cela ait pu le faire. Existe-t-il un index sur BATCH_INGR qui inclut à la fois FACTORY et INGR_CODE ? Vous pourriez en avoir besoin maintenant que vous incluez INGR_CODE dans vos conditions d'adhésion.
La meilleure façon de le savoir est de regarder le plan de requête avec et sans le INGR_CODE clause et voyez en quoi elle diffère. Le coût d'une requête est-il plus élevé que celui de l'autre ? Y a-t-il des scans de table là où il n'y en avait pas auparavant ? Une recherche d'index s'est-elle transformée en balayage d'index ?
