Автоматическое сжатие и восстановление базы данных MS Access

Question

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

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

1) Если база данных будет зашифрована, когда внешнее приложение (MS Access или .NET) попытается подключиться к ней, что произойдет? Это нормально?

2) Что SO рекомендует в качестве хорошего решения, чтобы заставить все интерфейсные приложения ждать, пока база данных MS Access не будет готова к использованию? Чем меньше изменений необходимо внести в интерфейсные приложения, тем лучше.

Спасибо!

Answer 1

Это довольно часто задаваемый вопрос среди разработчиков Access.

Есть две части:

1. код для резервного копирования и сжатия базы данных, который вы запланируете на сервере.

2. код, который вы вводите в свой интерфейс для автоматического выхода из системы всех пользователей одновременно, что позволяет запускать код из # 1.

Как правило, офис открыт только, например, с 8:00 до 18:00 по местному времени, поэтому обычно безопасно выгнать всех около полуночи, чтобы серверная часть была доступна для резервного копирования и сжатия, скажем, в 1:00, при подготовке к обычное резервное копирование файлового сервера, которое может произойти, скажем, в 2 часа ночи.

VBScript для резервного / компактного относительно легко написать. Если вам нужна помощь с этим, спросите.

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

Ключевым моментом является то, что вы должны спланировать оба конца этого, планируя и закрывая все соединения, которые остаются на время, которое запланировано для резервного копирования / сжатия.

Answer 2

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

1> Если клиент пытается получить доступ к базе данных, которая уплотняется / ремонтируется, я считаю, что клиенту переднего плана сообщают, что база данных недоступна и извлекается бесцеремонно. Я считаю, что вы могли бы написать обработчик ошибок для этого, но для этого требуется больше знаний VBA, чем я могу предложить.

2> Если это вообще возможно, при работе с несколькими клиентами - СУБД на бэкэнде всегда будет работать лучше, даже если это Microsoft SQL Server Express на запасной коробке Windows. У данных будет больше шансов не испортиться, когда произойдут «плохие вещи» (отключение от сети, блокировки клиентов и т. Д.). СУБД с транзакциями обычно является хорошим маршрутом для этого.

Что касается решения этой проблемы, я боюсь, что мне не хватает программных идей. К сожалению.

Answer 3

Книга Гарри Робинсона о Access Security посвящена этой проблеме.Это стоит прочитать.На веб-сайте Гарри (vb123.com) он продает набор инструментов с набором инструментов администратора и безопасности, включая один, который предупреждает каждую подключенную рабочую станцию, а затем отключает интерфейс через x секунд.

Книга:

Реальный мир Защита и безопасность баз данных Microsoft Access

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