The more I think about this, the more convinced I become that the intent of having NOT IN as part of the query was that someone was going to provide a list of employee ID values, and that the idea of using dynamic SQL was predicated on that being a comma delimited list of integers.   Of course, that's a particularly bad idea given the potential for SQL injection, for any kind of site that faces the world wide web, as just a few extra lines of code provided in an input line could then be a serious problem.   There's a fairly straightforward way to turn the ID values into a table and have a stored procedure use a parameter that is a table, which would then eliminate the need for any dynamic SQL.