Как мне заставить ms-access подключиться к ms-sql от имени другого пользователя?

StackOverflow https://stackoverflow.com/questions/50786

  •  09-06-2019
  •  | 
  •  

Вопрос

Как мне заставить ms-access подключаться (через ODBC) к базе данных ms-sql от имени пользователя, отличного от их идентификатора Active Directory?

Я не хочу указывать учетную запись в ODBC-соединении, я хочу сделать это на стороне ms-access, чтобы скрыть это от моих пользователей.Выполнение этого через ODBC-соединение вернуло бы меня обратно к исходной ситуации, которой я пытаюсь избежать.

Да, это относится к предыдущему вопросу: http://www.stackoverflow.com/questions/50164/

Это было полезно?

Решение

Я думаю, вы можете заставить это работать так, как вы хотите, если будете использовать "Соединение БЕЗ ODBC DSN"

Если вам нужно, сохраните свои ODBC DSN на компьютерах ваших пользователей, используя проверку подлинности Windows.Предоставьте вашим пользователям доступ к вашей базе данных только для чтения.(Если они создадут новый mdb-файл и свяжут таблицы, они смогут читать только данные.)

Создайте логин SQL, который имеет разрешение на чтение / запись в вашу базу данных.

Напишите процедуру VBA, которая перебирает ваши связанные таблицы и сбрасывает соединение, чтобы использовать ваш логин SQL, но обязательно используйте синтаксис "Без DSN".

"ODBC;Driver={SQL Native Client};" &
       "Server=MyServerName;" & _
       "Database=myDatabaseName;" & _
       "Uid=myUsername;" & _
       "Pwd=myPassword"

Вызовите эту процедуру как часть вашего кода запуска.

Пара замечаний об этом подходе:

  • У Access, похоже, проблема с информацией о подключении, как только вы переключаетесь с чтения / записи на только чтение и пытаетесь вернуться к чтению / записи без закрытия и повторного открытия файла базы данных (mde / mdb).Если вы можете изменить это один раз при запуске на чтение / запись и не менять во время сеанса, это решение должно сработать.

  • Используя соединение без DSN, вы можете скрыть учетные данные от пользователя в коде (предполагая, что вы предоставляете им файл mde, все должно быть в порядке).Обычно жестко кодировать строки подключения - не очень хорошая идея, но поскольку вы имеете дело с собственным приложением, вас должен устраивать такой подход.

Другие советы

Я думаю, вам придется запустить процесс MS Access под учетной записью, которую вы хотите использовать для подключения.Существуют различные инструменты, которые позволяют вам сделать это, такие как КПАУ.Этот инструмент также позволит вам зашифровать пароль.

Здесь мы признаем, что вы используете подключение ODBC к своей базе данных со встроенной защитой, так что вам не нужно / не хочется вводить значение username / pasword в строку подключения (что, по моему мнению, является правильным выбором).

В этом случае, к счастью, нет способа "имитировать" другого пользователя при подключении к данным.Признайте вместе со мной, что возможность создать такую вещь была бы огромным прорывом в комплексной безопасности!

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

При использовании Access затем вы можете решить во время выполнения, хотите ли вы открыть обновляемую таблицу или представление только для чтения.Это может быть сделано, например, во время выполнения, в form_Open событие, установив форму recordsource либо в таблицу, либо в представление.

@Филипп
Я предполагаю, что вы используете это слово признать как примерно эквивалентный понимать или, возможно соглашайтесь;в противоположность противоположности отрицать.

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

Еще немного предыстории проблемы:У меня есть ODBC-соединения, настроенные на каждой из рабочих станций пользователей с использованием аутентификации Windwos NT.Большую часть времени пользователи подключаются с помощью настройки MDE для использования этого ODBC-соединения - в этом случае у них ВСЕГДА есть возможность добавлять / обновлять / удалять данные.

Проблема заключается в том, что некоторые пользователи достаточно осведомлены о MS-Access, чтобы создать новый mdb и связать его с MS-SQL server.Затем они могут редактировать данные прямо в таблицах, а не проходить через приложение, которое выполняет определенный объем проверки и удержания вручную.И они Нравится делаю это, но иногда это все портит и вызывает у меня проблемы.

Что я надеялся сделать (с чем я только что поэкспериментировал), так это обновить ссылки на базу данных примерно так для каждой таблицы (Примечание:Для этого эксперимента я переключил подключение ODCB на аутентификацию SQL Server, а также добавил учетные записи на SQL server: только для чтения - который не может быть подвержен никаким обновлениям, и чтение и запись - который имеет полные привилегии на столе).

myTable.Connect = _
                "ODBC;" & _
                "DATABASE=" & "MyTestDB" & ";" & _
                "UID=readonly;" & _
                "PWD=readonly_password;" & _
                "DSN=" & "MyTestDB" & ";"
myTable.RefreshLink

это останавливает их редактирование, но я не могу заставить работать более позднюю readwrite

myTable.Connect = _
                "ODBC;" & _
                "DATABASE=" & "MyTestDB" & ";" & _
                "UID=readwrite;" & _
                "PWD=readwrite_password;" & _
                "DSN=" & "MyTestDB" & ";"
myTable.RefreshLink

Кажется, что к какому бы разрешению я ни подключился первым, оно остается неизменным.Если я запустил readwrite, а затем перешел в readonly, таблица останется с правами readwrite

Почему бы не использовать интегрированную систему безопасности Windows?Вы можете предоставить группе Active Directory нужные вам права пользователей, а затем добавить учетные записи пользователей в эту группу.Я полагаю, что вы также можете использовать функцию ролей sql server в дополнение к этому, чтобы ограничить функциональность в зависимости от используемого клиентского приложения.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top