Очистка кэша доступа - PullRequest
       11

Очистка кэша доступа

1 голос
/ 11 сентября 2011

Я разрабатываю систему в Access, разговаривающую с бэкэндом Sql Server. Я могу подключиться к двум отдельным учетным записям A и B, чтобы иметь возможность контролировать разрешения. В частности, у меня есть представление, доступ к которому осуществляется через сквозной запрос, который запрещен для A, но разрешен для B.

Обычно выбор A или B в качестве имени входа зависит от того, к какой группе безопасности доступа принадлежит пользователь, но я настроил его так, чтобы люди из группы «Администраторы» (т.е. я) считывали имя входа из внутренней таблицы доступа. Я также создал форму (и связанный код), которая позволяет администратору изменять это значение.

Все это прекрасно работает и отлично работает - при условии, что я запускаю Access с нуля .

Он определяет, что я являюсь администратором, читает последнее значение, которое я установил во внутренней таблице, подключается к серверу с правильной строкой входа в систему (я зацикливаю удаление и воссоздание всех таблиц с использованием этой новой строки подключения), а затем отображает мое первая форма. Я перехожу к кнопке, которая запускает сквозной запрос. Когда я нажимаю эту кнопку, он воссоздает сквозной запрос, удаляя запрос с тем же именем и воссоздающий его с правильной строкой соединения (логин A или B), а затем запускает его для вывода результатов. Если я - A, то происходит сбой с ошибкой разрешения (которую я отображаю и информирую пользователя), если я - B, это работает, и я получаю результаты.

Я добавил систему, чтобы попытаться изменить это на лету в целях тестирования. После изменения того, кому администратор должен войти в систему (путем записи во внутреннюю таблицу), он вызывает код запуска, который перебирает удаление и повторное создание таблиц, а затем возвращает меня к первоначальной форме.

ОДНАКО - если я теперь перейду к кнопке, которая запускает мой запрос с контролем разрешений, он все равно удаляет и заново создает запрос def с нуля, но когда я его запускаю, он, кажется, запускается в контексте входа в SQL Server. он устанавливается при первом запуске доступа, а не при новом входе в SQL Server, с которым я только что заново создал все. Таким образом, запрос будет выполняться, когда он не должен (наоборот).

Если я выйду из Access и попытаюсь снова - он снова начнет работать правильно.

Единственный вывод, который я могу сделать из этого, заключается в том, что где-то внутри Access он кэширует строку подключения ODBC - и вместо использования новой используется старая.

Итак, мой вопрос - правильный ли мой вывод, и если да, то как я могу сказать Access очистить его кеш.

Я занимаюсь разработкой в ​​Access 2010 - для системы, которая в конечном итоге будет работать в среде Access 2000 - поэтому формат файла - это .mdb в формате Access 2000.

Ответы [ 3 ]

3 голосов
/ 25 июня 2012

Я пришел к этой теме, потому что у меня возник тот же вопрос: «Как очистить кэш в Access 2010?»

В моем случае проблема заключалась в том, что мое приложение каким-то образом «запомнило» весь путь кмои связанные фотографии, хотя я ссылался только на имя файла.Одна из приведенных выше ссылок приводит меня к поиску в разделе «Файл> Текущая база данных> Кэширование веб-службы и таблицы SharePoint».Параметр «Использовать формат кэша, совместимый с MS Access 2010» уже был отмечен, но я установил флажок «Очистить кэш при закрытии» и закрыл базу данных.

Вуаля!Все ранее кэшированные значения, включая значения для моих связанных фотографий, были удалены.Не похоже, что этот параметр повлиял на мои соединения ODBC без DNS, но я не подтвердил это.

** ЧТОБЫ ОЧИСТИТЬ КЕШИНГ, перейдите в Файл -> ** ОПЦИИ -> Текущая база данных и прокрутите вниз до Кэширование веб-службы и таблицы SharePoint. ****

1 голос
/ 21 августа 2016

Насколько я знаю, нет способа очистить этот кеш. Если вы выполните запрос и предоставите другой UID / пароль для этого запроса, то разрешения, которые вы получили в результате этого действия, будут действовать до тех пор, пока вы не закроете Access.

Таким образом, если вы выполните другой запрос и предоставите «другой» UID / пароль, а затем в дальнейшем выполните другой запрос с «более низкими» разрешениями, будет использоваться другой кэшированный UID / пароль. Таким образом, вы можете (и будете) кешировать несколько UID / паролей в данный момент времени - вы не можете контролировать, какой из них используется.

Единственный способ обойти это - принять отдельный запрос ADO - насколько мне известно, он не кэширует учетные данные, как при использовании запросов DAO.

1 голос
/ 11 сентября 2011

Может ли эта страница о сбросе пароля доступа по ODBC быть тем, что вы ищете?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...