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

Question

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

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

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

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

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

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

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

Answer 1

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

Answer 2

Я предполагаю, что вы получаете доступ к файлу 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. Администраторам будет предоставлено право вставлять/обновлять/удалять, в то время как другие пользователи смогут просматривать данные. Это означает, что у вас есть где-то в вашей программе или, в идеале, в таблице, некоторые данные, указывающие, кто что в вашем приложении.

EDIT: После кратных комментариев с Corey:

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

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

Answer 5

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