Как я могу открыть Access DB через ADO, чтобы я мог писать, но другие могут только читать?

Question

Из документации я бы ожидал, что adModeShareDenyWrite будет подходить, но он работает неправильно.

Я использую базу данных Access через ADO. Моя строка подключения говорит Mode = 8, который является adModeShareDenyWrite. Но когда я пытаюсь удалить строку из таблицы, я получаю:

Неуказанная ошибка, Описание: не удалось удалить из указанных таблиц. Источник: Microsoft JET Database Engine

Другими словами, настройка не позволяет ME обновлять базу данных, используя мое СОБСТВЕННОЕ соединение.

Я обнаружил в сети пару других сообщений, сообщающих об этом же, настройка adModeShareDenyWrite, используемая с Access, не работает как описано.

Я ищу решение, не требующее изменения прав администратора. Это должно быть то, что моя программа может контролировать.

Моя мотивация здесь состоит в том, чтобы минимизировать вероятность повреждения базы данных. Одной из причин повреждения файла mdb, задокументированных Microsoft, является запись двух приложений в одну и ту же базу данных. Итак, я хочу убедиться, что только одно приложение может иметь подключение для записи в БД. Другие могут читать, но должны потерпеть неудачу, когда они пытаются написать. Тот, кто устанавливает соединение первым, побеждает.

Answer 1

Кори Трейджер писал:

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

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

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

Я думаю, что ваш страх коррупции неуместен.

С другой стороны, вы все равно должны иметь возможность открываться с помощью эксклюзивной блокировки, и я не уверен, почему она не работает. Рассматривали ли вы использовать DAO вместо ADO для управления данными Jet? Учитывая, что это собственный интерфейс данных (а не общий интерфейсный уровень), он должен быть проще.

Answer 2

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

Answer 3

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

Одним из решений будет управление параметрами вашего соединения, например:

(where you have a user object with a '.role' property, or anything equivalent ...)
if activeUser.role = "admin" then
    m_connectionMode = adModeWrite
else
    m_connectionMode = adModeShareDenyWrite
endif

Затем вы можете открыть соединение ADO с помощью параметра m_connectionMode. Администраторам будет предоставлено право вставлять / обновлять / удалять, в то время как другие пользователи смогут только просматривать данные. Это означает, что у вас есть где-то в вашей программе или, в идеале, в таблице, некоторые данные, указывающие, кто есть что в вашем приложении.

РЕДАКТИРОВАТЬ: Следующие кратные комментарии с Кори:

Вы не сможете делать то, что хотите, прямо. Мое предложение: когда приложение обращается к базе данных, оно проверяет наличие специального файла в папке .mdb (каким бы он ни был).

Если этот файл существует, приложение открывает соединение «только для чтения».

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

Answer 4

Кори Трагер писал:

Я ищу решение, которое не привлекает администратора изменение разрешений. Это должно быть что-то, что может контролировать моя программа.

Что ж, если проблема связана с тем, что разрешения NTFS доступны только для чтения для пользователя, вы ничего не можете сделать, чтобы сделать MDB доступным для записи. Вы не указываете, где хранится MDB, на сервере или на локальном жестком диске, но в любом случае, чтобы у пользователя были разрешения WRITE на MDB, необходимо разрешить NTFS-разрешения (для общего ресурса). на сервере это должно быть разрешено как для SHARE, так и для базового файла). Если это локальный файл, лучшее решение - убедиться, что вы храните файл в месте, в котором учетные записи на уровне пользователя имеют полное разрешение WRITE. Это будет где-нибудь в профиле пользователя, и нигде больше.

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

Answer 5

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