Исходные данные: руссифицированные MS Access 2003, Windows 7(у меня) и 10(у клиента).
Никак не могу понять что происходит. В запросе есть условие вида:

e.[Дата] BETWEEN Forms![WorkReport].DateFrom And Forms![WorkReport].DateTo

где DateFrom и DateTo объявлены как свойства типа Date, поле e.[Дата], разумеется, тоже дата, в смысле, native-datetime. Запрос является базовым для отчёта, который показывает записи за указанный период. У меня на компьютере всё прекрасно работает абсолютно независимо от региональных установок и способов, на компьютере же клиента, для которого по просьбе и правится старая уже программа, не работает ни один из многочисленных перепробованных мною вариантов. Никакие преобразования не срабатывают.
Например:

BETWEEN CDate(Forms![WorkReport].DateFrom) And CDate(Forms![WorkReport].DateTo)

и вовсе выдаёт известную ошибку о слишком сложном выражении. Формально, я знаю, что в Access SQL по сути единственным гарантированным выражением для даты является американский(#m.d.yyyy#), в который обычно легко преобразуется локальный при подстановке параметров запроса, например. Вроде как должна работать подстановка функций, возвращающих дату, как пример:

BETWEEN FuncDateFrom() And FuncDateTo()

Так вот на моём компьютере работает абсолютно все перечисленные варианты, у клиента-же, как заговорённый, никаких вариантов, кроме прописывание дат как литералов в американском стиле. Я безусловно могу везде, где это надо, жестко прописывать дату в этом стиле, но очень хотелось бы, чтобы всё-таки у клиента работало также, как на моём компьютере. Собственно, в этом и вопрос: может кто-то разбирался плотно, что на так может влиять на поведение в восприятии дат в Access SQL ? Версия Access у клиента и меня совпадают, правда у меня SP3, у него пока не узнавал, возможно это влияет. Просто не хочется мусорить литералами и постоянными преобразованиями в американский формат, очень некрасиво.

Upd. У клиента тоже SP3 и как выяснилось, формат воспринимается только #YYYY-MM-DD# и #YYYY/MM/DD#. Остальные, кажется, даже американский, нет. Просто феерия какая-то :(

Самое забавное, что у клиента как раз такое и стояло, это у меня уже старая привычка определять формат как YYYY-MM-DD, но игрища с изменениями формата не сыграли ни малейшей роли, у меня по-прежнему работали все варианты, у клиента нет, даже если он ставил краткий формат даты как у меня. Собственно, формат и не должен играть ни малейшей роли, если я однозначно определяю, что-то как дату. И свойства, которые я делал, по сути те же самые функции с указанным явно типом даты, там точно так же делается присвоение, как если бы я написал функцию. И у меня на компьютере это работает, а у него нет, вот в чём проблема. Я слишком давно активно работал с Access, уже лет 20 прошло и уже подзабыл про его закидоны, а вот теперь опять пришлось вспомнить
Это явно какая-то фигня, но всё что я просмотрел заново на эту тему, сводится либо к DateSerial, либо к литералам в американском стиле, хотя повторюсь, у меня на компьютере всё прекрасно работает без каких-либо литералов. Понадеялся, что может кто-то разобрался досконально с этим вопросом, но по ходу, увы, всё те же, всё так же.

Я не спрашивал о том, как сделать по-другому, я прекрасно знаю все эти убогие способы передачи параметров в формы/отчёты через текстовую строку. Меня интересовало другое, вдруг кто-нибудь разобрался досконально и знает почему на одних компьютерах прекрасно работают все варианты работы с датой, включая функции, а на других - только через "правильный" формат.

Не понял вопроса. Дата должна обрамляться, если она литерал, а их я как раз и не хочу использовать, ибо это неправильно. Тем более что речь об именованном сохранённом запросе, который используется в отчёте, а не как источник для рекордсета. У клиента изначально вообще абсолютно тупо менялся текст такого именованного запроса перед его вызовом как раз таким образом, с подобным форматированием конкретно заданными значениями даты. Теперь представьте такой вариант в многопользовательской среде, когда несколько человек пытаются одновременно использовать такой запрос в форме и каждый со своими значениями даты. Думаю не надо пояснять, насколько это неправильно, начиная с того, что пользователь не должен иметь возможность модифицировать именованный запрос в принципе.Поэтому меня не интересуют способы передачи даты как строки с # или без них, это я уже от безнадёжности начал экспериментировать, чтобы понять, что там у клиента в принципе работает. В случае строки запроса для "свободного" рекордсета прекрасно работают PARAMETERS, что тоже исключает необходимость в #. Таким образом, я в принципе не хотел связываться с форматированием значений даты в строке. Передача дат ли, чисел ли конвертацией в текст, давайте уж начистоту, это убого. И на моём компьютере всё, что я хотел, работает прекрасно, а вот у клиента нет, это и было главным моим вопросом, а не то, какие специи надо добавить, чтобы кошка получилась вкусной.

Прости, конечно, но я в курсе:) Еще раз, я вообще не хочу использовать литералы, если это в принципе возможно.

В модуль твоей формы я добавил

Скопировал твой запрос с другим именем и немного его поменял
И запрос открывается и показывает ровно то, что должен, без литералов и #. Вот я и хочу, чтобы у клиента работало так же.

Дело в том, что клиент удалённый, я не могу экспериментировать на его компьютере База разделена на данные и приложение, я ему пересылаю только исправляемое приложение, он проверяет, работает или нет. Я его и так уже загонял, но пока без толку. Кстати, вначале это было монолитное приложение два-в-одном, я программно разделил его на приложение и данные кодом, так что БД и так можно сказать с "нуля".

С файлом приложения всё нормально. Как я уже писал ранее, я пересылаю клиенту свою копию, которую он и запускает. А с доступом сложнее, эта программа стоит в государственной организации, где работают с закрытыми персональными данными, так что мне нельзя подключиться туда ни под каким соусом. Максимум, я могу попросить о каких-то технических деталях. Программа изначально написана как любительская, но не очень хорошо, поэтому решил помочь людям, которые делают важные дела. С моей стороны, это чисто благотворительный акт, простое желание помочь, никаких официальных отношений. Не совсем, исходно, у меня не текстовые поля, а стандартный объект-календарь(MSCAL.Calendar.7), мог обращаться напрямую к нему, но решил всё-таки получать значения через RO-свойство формы типа Date, аналогично приведённому выше примеру. Один из последних проверяемых вариантов

У меня-то работают практически любые варианты, в том числе и без DateSerial, это уже просто от безнадёги, на авось, хотя выглядит глупо, так как всё равно возвращается тип Date. Если бы не смогло конвертироваться, то вылетала бы ошибка при запуске запроса, как у клиента :) Первоначальный вариант был проще
и у меня он тоже работал.
Я уже подумывал, что это связано с тем, что я всегда в ОС выставляю себе краткий формат даты, совпадающий с ISO - YYYY-MM-DD, но когда клиент попробовал поменять у себя на такой же, то ничего не изменилось, кроме отображения дат, а код как не работал, так и не работает.

Разумеется, выглядит на редкость уродливо, но других-то вменяемых вариантов всё равно нет. Попытка скрестить коня и лань, jet и vba, абсолютно провальна, учитывая несовпадение типов. Прежде всего, именно типа даты, что особенно умиляет, так как на практике он один из самых необходимых в БД. И самое удивительное, в самом Jet SQL нет никаких функций конвертации данных типа CAST/CONVERT, что решило бы большинство подобных проблем. Ведь даже параметры у запроса есть, но и тут недоработали, так как нет простого способа подставить их в запрос, который используется в качестве источника данных для формы/отчета. Причем неявная подстановка параметров в запрос, используемый в качестве источника данных для элементов управления в форме, вполне возможна, хотя и смахивает больше на чит, так как нигде явно не декларирован. Впрочем догадаться о нём несложно, так как ноги идут из тех же ссылок на форму. Зато Access анализирует тип bounded-поля, чтобы понять тип Value, это прямо facepalm какой-то. Даже интересно, кому в MS пришла такая оригинальная идея ? Тут я не готов согласиться, очень даже удобная вещь для расширения функциональности. Вот я и хотел понять, где именно, и почему на одном компьютере конвертация срабатывает вполне ожидаемо, а на других - никак. Ну во-первых, это не решает мою задачу, а Jet SQL, внезапно, прекрасно "понимает" прямую ссылку на поле-календарь. И еще он, судя по всему, "понимает", если ему в условие в качестве даты подсунуть её же в целочисленном варианте, как бы неестественно это не смотрелось. Во-вторых, я не искал советов, как сделать по-другому, все предложенные тут способы знал ещё в 90х, так как довольно много писал на MS Access. Просто надеялся, что в 2003, с которым мне уже не пришлось поработать, предложили что-то более вменяемое, но увы, как выяснилось. Ну и в-третьих, исходные постановка подразумевает MSA2003. Лучшее решение, вообще реализовать требуемую функциональность на чём-то более вменяемом, но, увы, здесь тоже есть нюансы, руки связаны.

P.S. В принципе, тему для себя закрываю. Ничего нового, к сожалению, я не увидел

Любое использование компонентных технологий на свой страх и риск, но на то они и компонентные, чтобы не писать всё самому. ActiveX - обычный OLE-объект, который следует заданному протоколу обмена данных между приложениями и в среде Windows они сплошь и рядом. Впрочем, ваше право отказаться от их использования, а заодно и от чужих библиотек, и всего, что обнаружите в списке ссылок Access-проекта, а заодно и от самого Access. Всё сами, собственными руками, такая практика имеет место быть.

P.S. Вот обо всём мне рассказали, кроме того, что я действительно хотел узнать

Решено. На всякий случай, опишу причину проблемы, описанной в стартовом топике, вдруг кто-то ещё окажется в подобной ситуации. У клиента стояла безопасность(Сервис/Макрос/Безопасность...) на среднем уровне. В результате, процедуры из объектов MS Access, в данном случае - форм, не запускались внутри Jet SQL.