Ряд вопросов здесь.
если вы используете ADP для внешнего интерфейса к SQL Server, вы не будете использовать DAO, как вы не можете, так как ADP не используют Jet / ACE. После этого у вас будет прямое соединение ADO с SQL Server.
Однако в течение последних 5 лет MS отказывалась от ADP в пользу MDB / ACCDB с использованием ODBC (за исключением некоторых сценариев отчетности). В A2007 и A2010 не было никаких изменений в ADP, что может указывать на то, что MS планирует полностью отказаться от них (как они сделали с DAP после изменений в A2002 и A2003). Но может также случиться так, что MS планирует восстановить ADP в следующей версии Access, так как команда Access активно ищет информацию от тех, кто использует SQL Server.
При использовании рекомендованной технологии (MDB / ACCDB) с ODBC (и, предположительно, связанными таблицами) вы используете Jet / ACE, а логическим интерфейсом данных является DAO, собственный интерфейс данных Jet / ACE.
Jet / ACE на самом деле чертовски умен в работе с серверной базой данных, но он допускает ошибки, и есть некоторые типы запросов, которые могут написать неопытные разработчики Access, которые будут производителями с серверной базой данных (потому что они заставляют Jet / ACE, чтобы получить всю таблицу с сервера и выполнить всю работу на клиентской рабочей станции - см. Ответ @Philippe Grondier выше).
Обычный подход к работе с SQL Server через ODBC из MDB / ACCDB состоит в том, чтобы попробовать его способом доступа со связанными формами и целыми девятью ярдами (ничем не отличается от того, что вы разрабатывали для своего приложения для Jet / ACE back end), а затем с помощью SQL Profiler определите, какие части являются узкими местами в производительности и должны быть реструктурированы так, чтобы соответствующая обработка выполнялась на стороне сервера.
Разумное использование ADO часто оправдано, потому что есть определенные вещи, которые ADO делает блестяще, что DAO делает плохо или не делает совсем.
Но основная идея состоит в том, чтобы использовать тот же подход, что и при работе с серверной частью Jet / ACE, поскольку Jet / ACE управляет вашим интерфейсом с сервером. Это означает, что вам не нужно беспокоиться о различиях между диалектом SQL Jet / ACE и диалектом базы данных вашего сервера, потому что Jet / ACE и ODBC полностью устраняют эти различия.
Несколько случайных вопросов:
для наборов записей DAO, вам нужно добавить опцию dbSeeChanges.
очень важно, чтобы у всех ваших таблиц был первичный ключ, или у вас могут быть странные обновления экрана. Но у всех ваших столов есть ПК, верно?
Я считаю целесообразным указывать поле метки времени во всех таблицах SQL Server, даже если я никогда не использую его явно. Это (в сочетании с # 2) гарантирует, что обновления максимально эффективны (ODBC может проверять временную метку вместо необходимости сравнивать все поля на стороне клиента по одному со значениями на стороне сервера).
если вы используете сквозные запросы или ODBCDirect, вам нужно будет позаботиться о диалекте SQL базы данных вашего сервера и четко указать, какой SQL обрабатывается Jet / ACE (и интерпретируется для вас как внутренний диалект) и который идет прямо на сервер.
Jet / ACE не имеет типа данных, соответствующего bigint, поэтому если вы используете его в качестве PK в таблице SQL Server, вам придется обрабатывать его нестандартным способом. В базе знаний MS есть статьи, посвященные решению этой проблемы.
если вы используете ADO, помните, что ADO использует то, что Access называет «режим совместимости с SQL 92», что означает подстановочные знаки SQL Server и синтаксис производной таблицы.