Сохранить пароль для подключения ODBC к серверу MS SQL из MS Access 2007

Очевидно, что лучшим решением является использование безопасности Windows.

Если это не подходит, вот возможный альтернативный прием, использующий тот факт, что Access запоминает все открытые соединения, пока программа не будет закрыта:

1. скопируйте строку подключения одной из ваших таблиц
2. создать сквозные запросы «ptqConnect» и ввести в него любой быстрый оператор SQL, например SELECT 1
3. вставьте строку подключения в свойство PTQ Connect и убедитесь, что вы добавили в нее PWD=something;.
4. в процедуре запуска вашего приложения убедитесь, что вы вызываете этот PTQ. Что-то вроде DCount("*", "ptqConnect") подойдет.

Вот и все. Поскольку Access запоминает открытые соединения, пока вы не закроете его, даже если вы закроете базу данных, другие ваши таблицы теперь будут открываться без каких-либо проблем, даже если в связанных таблицах не хранится пароль. Строка подключения.
Если вы не хотите предоставив строку подключения, которая включает PWD, вы также можете инициировать подключение из VBA и скрыть код, доставив MDE или просто защищая код паролем.

Вы можете найти объяснение такого поведения здесь.

Сообщите пользователям, что политика безопасности вашей организации запрещает хранение паролей. Поэтому они должны предоставлять свой пароль каждый раз, когда открывают базу данных. Объясните, что эта политика запрещает неавторизованному пользователю возможность открыть базу данных с компьютера авторизованного пользователя. Если бы пароль был сохранен каким-либо образом, злоумышленник мог просто сесть за автоматическую машину и открыть базу данных.

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

Изменить. Поскольку ваш вариант № 2 приемлем, вы можете просто сохранить uid и pwd в строках подключения для таблиц, связанных с ODBC.

Вот пример, скопированный с connectionstrings.com

Driver={SQL Server Native Client 10.0};
Server=myServerAddress;
Database=myDataBase;
Uid=myUsername;Pwd=myPassword;

Я разделяю однострочную строку для отображения в браузере. Вам также необходимо определить, на какую таблицу указывает каждая из ссылок; изучите текущие строки подключения ссылки, чтобы увидеть, как это делается.

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

У меня была эта проблема с Access 2010, подключенным к SQL Azure, но это было очень просто. При связывании таблиц есть опция флажка для каждой таблицы, чтобы сохранить пароль.

Повторное связывание таблиц и установка этой опции решит проблему. Он дает вам предупреждения о том, что это может быть небезопасно, но не все базы данных содержат конфиденциальные данные.

Просто столкнулся с этой проблемой при удаленном подключении к моему серверу sql на рабочем месте с помощью Access. У меня есть Access 2013, но я не думаю, что он внес какие-либо изменения в что-то настолько простое, как соединение ODBC с 2010 года. Поскольку это не доверенное соединение, да, вам придется входить на сервер каждый раз, когда вы подключаетесь к база данных. Это просто базовая безопасность; Не могу представить, зачем вам когда-либо нужно, чтобы приложение просто беспрепятственно подключалось из ненадежной сети. Итак, я ожидаю, что мне придется войти в систему при открытии базы данных.

Однако что сводило меня с ума, так это то, что каждый раз, когда я пытался открыть таблицу, меня спрашивали пароль, и не один раз, а дважды, и я должен использовать пароль из 13 символов, который был сгенерирован случайным образом при создании! Так что, разумеется, это было совершенно неприемлемо.

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

Но использование db в Access в качестве локального файла означает, что я внимательно следил за именами DSN-подключений. Пока они абсолютно идентичны на всех компьютерах, это прекрасно работает. Итак, если мой DSN был назван «ProductsDBIII», когда я создавал его на работе в инструменте ODBC32 Windows, то мне нужно использовать это же имя при создании его дома. Фактическая строка подключения будет другой, но Access это не волнует. Однако вот в чем уловка: когда я впервые использую БД из дома, например, после рабочего дня, мне нужно обновить соединения в диспетчере связанных таблиц Access. Просто отметьте нужные таблицы / представления или «Отметьте все» и вперед. Access установит соединение - вероятно, предложит вам войти в систему - а затем быстро обновит строковое поле «connect» в таблице MSysObjects, потому что они будут другими, по крайней мере, при переключении с доверенного доступа.

Вуаля, больше никаких одиночных или двойных испытаний каждый раз, когда я открываю стол. Меня спросят один раз, когда я впервые устанавливаю соединение при первом открытии таблицы из удаленной БД, но это все.

Надеюсь, это кому-то поможет.

Джим

Повторное использование Passthrough QAuery для установки соединения ODBC.

Форма, указанная как форма запуска в параметрах базы данных, будет запущена ПЕРЕД autoexec. Таким образом, эта форма не может / не должна цитировать связанные таблицы или не указывать их; и установите форму в autoexec.

В противном случае вам все равно будет предложено ввести pwd для подключения ODBC.

Типичный сценарий проблемы - использование формы Switchboard с таблицей в связанной базе данных.