А какая версия Access?
У меня та же проблема, но появилась при переходе с 2000-го на 2002-й
Сейчас ищу способы решения.

2 Владимир Саныч
DoEvents - не помогает однако :)

2 Витал
Меняется RecordSource субформы (хранимая процедура) и, как водится, Requery субформы.
Кажись Requery - лишнее, т.к. изменение RecordSource уже само по себе обновление.

2 АлексейК
Можно даже без подформы, сделать поле с функцией, которая вернет результат запроса типа
"select sum([field]) as f1 from (" & Subform.Recordsource & ") a"
и сделать это можно через Command.Execute

Дело в другом:
Использование дополнительных запросов, для расчетных полей, не очень хороший метод, особенно для больших систем (много пользователей * много данных), т.к. идет лишняя нагрузка на сеть и на сервер.

Ведь если запрос уже выполнен и записи на клиенте, то подсчитать сумму по какому-то полю - это работа клиентской части.

Тут явная ошибка Access...вопрос в том как она решается без способов "чешу левое ухо правой задней ногой"

Раз уж есть желающий протестировать - грех такой возможностью не воспользоваться :)

Уж извините, что вмешиваюсь, просто именно в данный момент занят решением этой проблемы (точнее поиском приемлемого варианта).
У меня немного другая история, но очень близко к проблеме, которую описывал Витал, и решение думаю будет одинаковое.

Как я воспроизвел макисмально просто проблемную ситуацию.
Таблица из двух полей (ключ+денежное поле)
Форма1 - создается мастером в виде ленточной.
В примечании формы делаем поле =SUM([наше денежное поле])
Все работает прекрасно: сумма считается правильно, даже при сортировке по ключевому полю вверх, вниз.
Теперь делаем простую форму (форма2) без источника и в нее добавляем созданную подчиненную Форма1.
Теперь при открытии сумма считается, но стоит только применить сортировку, как в итоговом поле идет ошибка.

Пока что найдено только одно решение - дополнительный запрос на подсчет суммы (как это реализовано значения не имеет, кнопка, поле, подформа - это уже кому как нравится).

2 Latuk
Можно подробнее о "фиктивном источнике"

Кстати в отличии от MDB в ADP агрегирующие поля в примечании формы типа = Sum([Сумма]) (причем [Сумма] не имя контрола , а имя поля источника) считаются на сервере и не реагируют на пользовательские фильтры

Откуда такая информация? Profiler ничего подобного не показывает.

2 вадя
У Витала возможно проблема именно со строкой синхронизации и уникальной таблицей (хотя я не уверен).
Что касается моего случая, то выяснил следующее: при использовании именованных запросов (таблица, вью, ХП) ошибка не возникает, если же использовать запрос в виде строки, то идет ошибка. И не имеет значения, установлена уникальная таблица и строка синхронизации или нет.
Самое обидное, что ничего подобного не было в 2000-м.

2 вадя
програмно заполняй "однозначную таблицу" и "команду синхронизации"
ПРАВИЛЬНО и будет работать

Будет работать но не всегда.
И команда синхронизации и уникальная таблица, не влияют на агрегирующие поля (это не факт а опытное замечение: при условии что в источнике запрос на основе одной таблицы зависимости обнаружить не удалось).
Цитата из Гетца: "Access не всегда может определить без вашей помощи как ей обновлять данные в тех случаях когда форма базируется не на одной таблице, а на объединении записей из нескольких таблиц...Устанавливать эти свойства нужно не всегда, а в зависимости от источника формы."

2 Latuk
Спасибо за пояснение о фиктивном источнике, сам что-то подобное использовал.
Если информация из опыта, то это не факт, при всем уважении. Тут необходимы доказательства :))
На 2000-м остаться не могу, т.к. имеется Office XP Developer и для клиентов будет устанавливаться Access XP Runtime.
Хотя если в общем, то в XP мне нравится больше.

Например у нас в центральном офисе более 100 машин , убедить сисадмина переустановить офис на всех было очень сложно , и даже когда убедил (через директора) прошло 4 месяца прежде чем исчехз последний юзер с MSO2000.

Вот поэтому и прошлось приобретать Office Developer.
Runtime вещь классная, причем прекрасно дружит MSO2000

Сколько будет весить установщик RunTime версии для Акеса2002 (mdb), если в проекте используются библиотеки DAO,ADO, mscomctl.ocx, микрософт object liblary - mco.dll, excel object liblary - excel.olb, ole atomation. хотя бы приблизительно

Приблизительно:
Чистый Access Runtime 35 Mb
OSP - обновление системных файлов (Windows Installer, IE5 и прочая ерунда) 87 Mb

Если нужно создавать свой пакет с включением дополнительных библиотек, то используется Pakage Wizard и конечный пакет инсталляции может получится немного больше.
У меня получилось:
MSDE+Access Runtime+все рабочие файлы = 250-300 MB

2 Senin Viktor
Зависит от (...впишите свой перечень...)
Но могу сказать что коробка она завсегда коробка - даже юзер, знакомый с процессом установки новых игрушек. Сможет установить программу упакованную в коробочную версию.