Любые категоричные суждения ошибочны от рождения...
(c)IMHO :)

Access (2000 и 2002) - это не один продукт (как было по Access97), а два. В одном разрабатываются MDB, в другом ADP. Прежде чем о чем-либо говорить, необходимо уточнить, о чем мы говорим. Если об ADP (а это и есть главное достижение двух последних версий), то высказанные суждения звучат просто смешно - они высказаны человеком, который не знает, что такое ADP. На самом деле ADP - это клиентская часть как раз для работы с MS SQL Server, которая в совокупности со средствами RAD MS Access (большинство которых дублирует возможности EM) позволяет удобно разрабатывать из единой среды клиентскую и серверную часть, а также выполнять простейшие функции по администрированию SQL Server-а. Однако, смешно сравнивать в этом случае снаряд с пушкой - одно без другого просто груда бесполезного железа.
Если речь идет об MDB, то нужно сразу заметить, что по человечески организовать проектирование и доступ к данным в клиент-серверных технологиях там не получится. Не то, чтобы совсем, но современные технологии (ADO) там фактически не используются и, насколько мне известно, не собираются использоваться в дальнейшем (упор уже идет именно на ADP).
Если речь идет об MDB без клиент-серверных технологий, то это уже файл-серверное приложение. Если сравнивать его с MS SQL, то сравнение некорректное. MS SQL - только серверная часть и только клиент-серверных приложений. В пару ему нужен какой-нибудь клиент (в качестве которого может выступать тот же Access-овский ADP (а еще может Delphi, VB as is, VFP, C++ etc). Если речь идет о сравнении технологий как таковых - клиент-серверной и файл-серверной, то тут тоже однозначного ответа нет. Для небольших объемов информации и небольшого числа пользователей файл-серверные оказываются более удобными (они более гибкие, менее требовательны к грамотности сопровождающего персонала, более мобильны и просты). Когда речь идет о больших объемах информации, о непрерывной работе с нею большого количества пользователей, файл-серверные приложения просто упираются в пределы своих возможностей. Основные ограничения файл-серверных приложений - низкая надежность и перегрузка локальной сети передачей больших объемов избыточной информации между файл-сервером и многочисленными приложениями на компьютеры пользователей (не следует забывать, что информация обрабатывается целиком каждый раз на компьютере пользователя).
Именно для случаев, в которых начинает существенно сказываться перегрузка сети, когда высокие требования к надежности информации, когда высокая нагрузка со стороны большого числа пользователей, выигрывают клиент-серверные технологии. Ошибочно полагать, что любое клиент-серверное приложение заведомо лучше файл-серверного. Можно с высокой степенью вероятности утверждать, что для одного-двух пользователей файл-серверное приложение будет работать быстрее, нежели в аналогичное в технологии клиент-сервер.
Если же попытаться сравнивать просто диалекты SQL T-SQL и SQL MS Jet (то есть ядра Access), то между ними действительно есть отличия, причем существенные. В MDB нет понятия триггеров. В MS SQL - есть. И я считаю это плюсом SQL Server-а. В SQL-запросах Access можно вызывать функции, написанные на VBA. Это плюс уже Access... Но с помощью этих функций нельзя сделать аналог inline UDF в T-SQL (чтобы функция возвращала набор данных, который можно использовать в поерациях JOIN и UNION). Правда, в Access есть запросы с параметрами, кторые чем-то похожи на inline UDF, однако по удобству их использования в подзапросах и всем остальном, что связано с модульным подходом в программировании, inline UDF в T-SQL неоспоримо лучше. DRI с каскадными операциями есть и там, и там (правда в Access они появились еще в древних версиях, а в MS SQL каскадные операции возникли только начиная с версии 2000).
Я не хочу сказать, что Access - хуже. Я уже говорил, что сравнение не совсем корректное. В Access (MDB) визуальный интерфейс очень тесно завязан с данными. Можно на ходу изменяя свойства визуальных компонентов (в виде SQL-запросов, или данных для QBE-запросов) получать сходу выборки нужной информации с удобной визуализацией... Но механизмы визуализации сравнивать с MS SQL Server просто некорректно - он для этого и не предназначен. Если же их сравнивать с Delphi, то тоже не совсем корректно - Delphi содержит средства ТОЛЬКО визуализации, но не содержит собственных форматов хранения реляционных данных. Правда, он имеет собственное ядро (BDE, аналог DAO MS Assess) для доступа и управления данными "чужих" форматов. Опять же, о чем мы говорим - о визаулизации? О ядрах? Ядра примерно одинаковые, по крайней мере я между ними существенных плюсов/минусов не вижу...
Визаулизация? Что-то удобнее и быстрее делается в Access, а что-то там в принципе сделать невозможно (попробуйте, например, сделать MDI-приложение, либо многопоточное приложение). Всегда были проблемы с выделением цветом в табличных и ленточных формах отдельных строк (в Delphi подобные проблемы кажутся просто смешными). Об ООП до недавнего времени в Access говорить вообще не приходилось. А в Delphi приходилось, и давным-давно... Delphi умрет скоро? Пока что-то подобных тенденций не замечено. Опять же, если вы разрабатываете распространяемое прлиложение, то следует учитывать, что Access не может создавать exe-файлов, в отличие от Delphi.
IMHO, более корректным является сравнение VB и Delphi, нежели Access и Delphi. Если сравнивать с MS SQL, то MySQL, Oracle, InterBase, DB2 и т.п. Но только не Access. С чем же можно сравнить Access? Ну, например, с Clarion или с VFP (IMHO). Но это уже отдельный разговор.

РЕЗЮМЕ. Вопрос сравнения MS Access с MS SQL поставлен некоррктно.