Я бы не согласился со всеми ответами, приведенными здесь, даже если они отвечают на заданный вопрос. Я не согласен, потому что думаю, что вопрос основан на неверных предположениях - нет необходимости переписывать SQL вообще.
Вопрос, похоже, предполагает, что запросы в Access должны быть сохранены. Они не Вы можете выполнить любую произвольную строку SQL в любое время, либо в коде, либо (для не-DML SQL) в качестве источника записей формы или отчета. Строки SQL могут создаваться на лету и назначаться по мере необходимости во время выполнения - единственное преимущество сохраненного QueryDef - это необходимость его использования в нескольких местах.
Сохраненный QueryDef в основном совпадает с VIEW в базах данных сервера.
Если у QueryDef есть параметры, это эквивалентно простой ХРАНЕННОЙ ПРОЦЕДУРЕ (т. Е. Без кода, например, ветвление IF / THEN или CASE SELECT).
Если вы хотите реализовать SQL как VIEW в базе данных сервера, сохраните его как QueryDef в Access. Если вы сделаете это как SPROC в своей базе данных сервера, реализуйте его как запрос сохраненного параметра.
Но прежде всего определите, нужно ли его вообще сохранять.
Что бы это ни стоило, я профессионально программирую в Access с 1996 года, и я обычно не сохраняю много запросов, и особенно не сохраняю критерии в запросах. Критерии специфичны для контекста времени выполнения и должны предоставляться во время выполнения, а не сохраняться в QueryDef. Я использую сохраненные QueryDef для сложного SQL, который мне нужно использовать повторно, или для определения «представлений» (особенно тех, которые имеют сложные объединения), которые используются в нескольких местах приложения.
Оригинальный вопрос не определяет контекст, в котором необходимо изменение критериев, поэтому действительно невозможно предложить лучший подход. Это тот случай, когда я ошибся в вопросе об исключении надлежащего обсуждения, поскольку в нем предлагается конкретное РЕШЕНИЕ и спрашивается, как его реализовать, вместо того, чтобы описывать ПРОБЛЕМУ и запрашивать диапазон выполнимых решений. Чтобы сделать последнее, нам нужно знать о контексте (является ли SQL DML или SELECT? Используется ли он в коде или как источник записей для формы или отчета? И т. Д.), Но здесь этого совершенно не хватает поэтому полный спектр решений никогда не будет предложен.