Если вы обращаетесь к нему через ODBC, вы можете включить ведение журнала ODBC. Однако это сильно замедлит ход событий. И это не будет работать для любого другого интерфейса данных.
Другая мысль заключается в использовании Jet / ACE в качестве связанного сервера в SQL Server, а затем в SQL Profiler. Но это скажет вам SQL, который обработал SQL Server, а не то, что обработал Jet / ACE. Это может быть достаточно для ваших целей, но я не думаю, что это будет хорошей диагностикой для Jet / ACE.
EDIT:
В комментарии оригинальный постер предоставил довольно важную информацию:
Приложение, которое я пытаюсь контролировать
составлен и у клиента
предпосылки. Я пытаюсь контролировать что
запросы, которые он пытается против
MDB. Я не могу изменить приложение.
Я пытаюсь сделать то, что SQL Profiler
будет делать для SQL Server.
В таком случае, я думаю, что вы могли бы сделать это:
переименуйте исходный MDB во что-то другое.
использовать связанный сервер SQL Server для подключения к переименованному файлу MDB.
создать новый MDB с именем исходного MDB и связать его с SQL Server через ODBC.
Результатом будет файл MDB, в котором есть те же таблицы, что и в оригинале, но они не локальные, а связаны с SQL Server. В этом случае весь доступ будет осуществляться через SQL Server, и его можно просмотреть с помощью SQL Profiler.
Я не имею ни малейшего понятия, что это скажется на производительности, или если это нарушит какой-либо поиск данных в исходном приложении. Если это приложение использует наборы записей табличного типа или SEEK, то да, оно сломается. Но это единственный способ, который я вижу, чтобы войти в систему.
Не удивительно, что для Jet / ACE нет ведения журнала, учитывая, что нет единого серверного процесса, управляющего доступом к хранилищу данных.