Все не так просто, как кажется. Прежде чем что-то делать, необходимо задаться вопросом - ЗАЧЕМ? Файл-сервер тормозит, и вы полагаете, что переместив методом параллельного переноса таблицы на SQL-сервер, добъетесь увеличения быстродействия?
Увы, это заблуждение.
SQL-сервер дает выигрыш в быстродействии при соблюдении следующих условий:
1. Большие объемы данных
и/или
2. Большое количество пользователей

Почему тормозит файл-сервер? Потому что для выборки пары записей по сети на клиент, грубо говоря перекачивается содержимое всей таблицы (на самом деле, если есть индесы, то не вся таблица, а некоторые ее части и индекс).
Что изменится, если ты прилинкуешь таблицы к MDB, разместив их на SQL-сервере? Ничего! JET производит выборку нужных записей, скачав через DAO то же, что качалось бы с файл-сервера.
Когда же реально клиент-серверная технология приносит выигрыш? Когда изменяется идеология приложения, перераспределяются задачи, выполняемые клиентом и сервером. Важно найти оптимальное распределение между клиентом и сервером. Жутко тонкий клиент - тоже не всегда дает выигрыш в бытродействии (особенно при большом числе пользователей). Возможно, даже имеет смысл пересмотреть схему данных. Необходимо оценить, какие операции должны выполняться на сервере с помощью триггеров, хранимых процедур и т.п., а что лучше делать на клиенте. При решении этих вопросов исходят из того, что по сети должен передаваться такой объем информации, чтобы сеть не стала узким местом (как происходит с файл-сервером). В то же время количество информации должно быть таким, чтобы черезмерно не перегружать SQL-сервер. Например, сортировку в разных разрезах уже выбранной с сервера информации удобно делать на клиенте в ADO Recordset-е.

Резюме. При переходе на клиент-серверную технологию рекомендую сразу переделывать все под ADP (если ты хочешь при этом остаться на Access).