Развели тут трескотню про ускорение!
Вот господа опыт мой, приложение Access и работа ведется сетевая, но больших задержек не наблюдается. Вначале я долго мучался. Представьте себе, условия на целостность на файл- сервере все возможные. Пользователь хочет ввести запись в форме которая включает в себя еще две связанные таблицы. Как только вводится первый символ, система отвечает, что соответствующих записей в связанной таблице не найдено, и предлагает закрыть окно без сохранения.
Вероятно, это наиболее часто вводит в заблуждение неопытных разработчиков. Между тем существует способ, как сделать это правильно, хотя может быть в ущерб простоте, однако, взамен можно получить преимущества, которые трудно переоценить. Особенно при работе в сетевой среде.
Для того чтобы без проблем ввести новую запись, необходимо временно отключить условия поддержания целостности данных вручную. Это можно инициировать из VBA, затем вводим новую запись, и за этим снова восстанавливаем условия целостности. Если подумать, то картина не радостная, Вы собираетесь ввести запись, отменили условия целостности, внесли запись, возможно при этом моргнул свет, и ваши связанные (посредством OLE) таблицы так и остались ни как не связанными (по ключевым полям) между собой.
Допустим, мы локально отменили условия целостности и если восстановление целостности не проконтролировать можно долго пялиться в трудом созданный вами отчет на основе многоуровневого запроса и не понимать, отчего данные дублируются?
Так ни кто не работает.

Тут была речь о том, что допустим некая девушка вводит данные допустим из анкет, результат работы ей не требуется (вероятно имелось ввиду, что ей не нужно сразу просматривать результат, однако результатом работы этой девушки является гарантированное наличие внесенных ею данных, минимальный лично ее ущерб БазеДанных- те., либо гарантированное отсутствие «кусочков информации» вследствие отключения света в критичный момент). Может у Вас, и стоят UPS, однако ваш хаб или свитч вряд ли додумались подключить к бесперебойнику. Она вносит данные в серверные таблицы, и допустим несколькими запросами данные из анкет попадают сразу в несколько таблиц. В любом случае таблиц будет несколько, коль речь идет о реляциях. Тут два пути, либо кутерьма с разрывом и установлением связи, либо вообще для безвопросной работы таблицы связываются непосредственно в запросах, а не в окне установления связей Access.
Вместе с тем мы знаем, что информацию необходимо хранить в таблицах, между которыми существуют отношения, иначе ввиду многократного повторения схожих данных ваша база вспухнет, и перестанет быть сколь ни будь подвижной. Приводилось много примеров того, как не надо хранить данные. Верхом криворукости считается использование для хранения и обработки данных так называемые «плоские» таблицы (существующие независимо и не в связи с остальными), правильно, хранить не надо, а надо использовать с умом.
Наша девочка сидит, и набивает данные анкет, вот ввела она все, допустим, есть десяток на текущий момент, нажала кнопочку и готово. Именно так мои девчонки и работают. Служу я местном облгазе. Приносят нашим операторам пухлые пачки из банков, где написаны фамилии и суммы оплативших людей, и вносят они в базу таких записей бывает по 200-300 штук за день. Девчонки с опытом и скоростницы, представляете если бы они ждали по несколько минут обновления на сервере единственной записи? Несомненно, будут и были взаимоблокировки. Так вот, у меня они вносят данные в самую плоскую таблицу, вносят сразу или не сразу, обслуживают, что-то делают еще, а потом одним единственным запросом и разносит все данные в серверные таблицы. В запросе этом на обновление есть плоская таблица информация, из которой обновляет связанные между собой серверные, одной единственной операцией. – это обновление.
А вот как происходит добавление совершенно новой записи. У одного абонента существует до 50 признаков логических и более 150 значений по категориям. Т.е. абонент может быть отключен, не отключен, со счетчиком, без него, может самовольно подключиться и т.д. Большинство признаков проставляются помесячно, т.е. могут быть, потом (допустим отключился) исчезают… Как добавить столько параметров? Конечно все автомат. Опять же на подхвате плоская таблица, поля которой соответствуют всем полям необходимых серверных таблиц. Абонент добавляется опять же одним простым запросом, а все предшествующие ему запросы форматируют и подготавливают нашу одномерную таблицу локально. Это гораздо быстрей чем насиловать серверные. При такой постройке СУБД речь одет о долях секунд.

Оскорить не хотел! Иногда кажется (может ошибаюсь), что существуют и более простые фишечки, хотя конечно же это все уже и придумано и и используется. Одна только System R чего стоит.! Это просто так Ни раздражение, ни крик, а просто реплика.