Вот вопрос...
Посоветуйте пожалуйста стоит ли пить виски или лучше обойтись водкой.
Все зависит от желаний и условий.
Причем от ОГРОМНОГО количества условий.

вопрос № 1 где будут храниться данные ?
ADP подразумевает наличие SQL сервера, вы к этому готовы?

Может.
Но работа с SQL сервер из MDB, тоже очень сильно отличается от работы c данными в MDB.
Так же необходимо переучиваться использовать возможности SQL сервера.
Кроме того ODBC в принципе не очень быстрое соединение.
Необходимо где возможно использовать запросы к серверу, а не обычные связанные таблицы
Если данные будут однозначно на SQL сервере и нет сильных ограничений по времени разработки я бы выбрал ADP.
Тут Валерий Крук (KrukVN) высказывал мысли по поводу использования в MDB для соединения с сервером ADODB, подсовывая формам открытый рекордсет. Это позволяет остаться в MDB при этом используя более быстрое соединение, но как это будет на практике лучше у него спросить

сильно теоретически
Если только вы сразу все запросы будете писать в синтаксисе T-SQL не используя функция ACCESS

Для начала, я думаю, нужно определится с тем, какую СУБД предпочтительнее использовать для решения поставленной задачи:
- файл-серверную
или
- клиент-серверную
если клиент-серверную, то в случае с ADP Вы будете жестко привязаны к одному источнику данных -> MS SQL Server. Другой альтернативы для ADP наверное и нету.
Если Вас ЭТО устраивает, то лучше сразу переходить на ADP, т.к. потом (если все-же начнете с mdb, а потом решите переселяться на adp) будет трудно.
*
а вот если захочется и другие СУБД 'пощупать', то наверное лучше оставаться в mdb в связке с ado.
а может вообще стоит слазить с акса

Еще один вопрос из области философии

Сколько займет времени чтобы начать более менее разбираться в ADP

Уверен что многие это уже проходили
Может кто обозначит конкр.временные рамки, основываясь на своем опыте

Если для этого достаточно прочитать одну книжку это одно, а если на освоение уйдет ну например полгода то это уже другое.
Начинать программу надо сейчас

ЗЫ Всем хороших выходных
и спасибо за содержательные ответы

ODBC - устаревшая и не актуальная технология.
Нет смысла сейчас ее защищать, оправдывать и тем более сравнивать с ADO например (про ADO.NET вообще промолчу). Если начинать изучать и разрабатывать клиент-серверные приложения, то на ODBC смотреть уж точно не нужно.
ODBC можно рассматривать как некий компромисс для задач, по быстрому переведенных с файл-сервера и не более.

Насчет ADO: ADO=ODBC + ActiveX. т.е опять же медленнее, чем чистый ODBC. Я не прав?

Зависит от типа используемого драйвера. Нужно просто не ODBC-шные дрова использовать.
Посмотрите например сколько типов соединений можно сделать только к одному MS SQL Server: http://www.connectionstrings.com/?carrier=sqlserver
там кроме odbc есть и oledb и net и еще что-то
Для MySQL: http://www.connectionstrings.com/?carrier=mysql

P.S. Да, кстати, может быть Вы имели ввиду ODBC-линковку серверных таблиц/видов и обращение к ним через ado?
Зачем? Нужно сразу на ADO и не к линкованным таблицам. Посмотрите скрин: таблиц в окне БД нет вообще, потому что обращение к ним идет напрямую (минуя ODBC).
Кстати, при таком подходе можно не беспокоится о защите от шифта и от шаловливых ручек пользователей. Ну хотя-бы на уровне интерфейса

как можно в запросе к серверу ( Запросы - Создать, Запрос - Запрос SQL - к серверу) использовать "не ODBC-шные дрова "?

так конечно нельзя :)

а вот при помощи ADO - можно. Про что я собственно и говорил ранее. Видели скрин? Там нет таблиц, и запросов нет (в соотв. вкладке окна БД) ни к серверу, ни каких-либо еще. А данные в формах есть. Юзайте ADO и все вопросы пропадут.