Файл базы данных ошибок Subd поврежден

Обновлено: 21.11.2024

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

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

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

Я пытался экспортировать все объекты базы данных в текст, начиная с совершенно новой базы данных, и снова импортировать их все, но это не решает проблему. Как только я импортирую все объекты в чистую базу данных, проблема возвращается.

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

Я искал объяснение, но пока не нашел. У кого-нибудь есть предложения?

EDIT: база данных включает несколько ссылок в дополнение к стандартным:

Объекты данных Microsoft ActiveX 2.8
Майкрософт Офис 12.0
Среда выполнения сценариев Microsoft
Регулярные выражения Microsoft VBScript 5.5

@HansUp все используют Access 2007. Пользователи получают собственную копию базы данных из сети, а данные находятся в связанных таблицах, указывающих на SQL Server.

Я предполагаю, что база данных разделена, передняя часть копируется для каждого клиента, а задняя часть находится в общей папке?

Отсутствующие ссылки @HansUp не являются проблемой. Я могу воспроизвести проблему на своем компьютере, где ссылки определенно не проблема.

1 Ответ 1

Некоторые вещи, которые я делаю и использую при отладке Access:

Протестируйте мое приложение на нескольких ВМ. Вы можете использовать HyperV на Win8, VMWare или VirtualBox для настройки различных контролируемых тестовых сред, таких как тестирование на WinXP, Win7, Win8, 32-разрядных или 64-разрядных версиях — всего, что соответствует диапазону ОС и разрядности ваших пользователей.

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

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

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

Убедитесь, что вы везде используете одинаковые версии Access: если вы используете Access 2007, убедитесь, что ваша машина разработки также использует эту версию и что все остальные пользователи также используют только эту версию и что нет компонентов из Access 2010. /2013 присутствуют.

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

Как правило, убедитесь, что ваше приложение компилируется без проблем (я имею в виду выполнение команды "Отладка" > "Компилировать" из IDE). Любая проблема на этом этапе должна быть решена.

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

Точно так же убедитесь, что вы правильно уничтожаете любой COM-объект, который вы создаете в своих классах (и подпрограммах/функциях). Деструктор Class_Terminate должен явно очищать все.Это также справедливо при закрытии форм, если вы создали COM-объекты (вы упомянули об использовании ADOX, объектов сценариев и регулярных выражений). В общем, отслеживание созданных объектов имеет первостепенное значение: убедитесь, что вы явно освобождаете все свои объекты, сбрасывая их (например, используя RemoveAll в словаре, а затем присваивая их ссылку Nothing .

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

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

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

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

Если вы используете пользовательские действия на ленте, убедитесь, что они не вызывают проблем. У меня со временем были странные проблемы с лентой. Зарегистрируйте все вызовы функций, сделанные лентой.

Файлы базы данных могут быстро увеличиваться по мере их использования, что иногда снижает производительность. Они также могут иногда портиться или повреждаться. Вы можете использовать команду «Сжать и восстановить базу данных», чтобы предотвратить или исправить эти проблемы. Компактный процесс не сжимает ваши данные — он уменьшает размер файла базы данных за счет устранения неиспользуемого пространства. Команда «Сжать и восстановить базу данных» также может помочь повысить производительность вашей базы данных.

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

Что вы хотите сделать?

Способы сжатия и восстановления базы данных

Существует несколько подходов к сжатию и восстановлению базы данных. Обычной практикой является автоматическое сжатие и восстановление базы данных при ее закрытии. Кроме того, вы можете вручную запустить команду «Сжать и восстановить базу данных», когда база данных открыта, а также для неоткрытой базы данных.

Прежде чем начать

Перед началом операции уплотнения и восстановления выполните следующие действия:

Создайте резервную копию базы данных. В процессе восстановления Access может обрезать некоторые данные из поврежденных таблиц. Иногда можно восстановить эти данные из резервной копии. В дополнение к вашей обычной стратегии резервного копирования вам следует сделать резервную копию непосредственно перед использованием команды «Сжать и восстановить базу данных». Дополнительные сведения см. в статье Защита данных с помощью процессов резервного копирования и восстановления.

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

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

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

Автоматически сжимать и восстанавливать базу данных при ее закрытии

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

Выберите «Файл» > «Параметры».

В диалоговом окне "Параметры доступа" выберите "Текущая база данных".

В разделе "Параметры приложения" установите флажок "Сжимать при закрытии".

Закройте и снова откройте базу данных, чтобы параметр вступил в силу.

Вручную сжать и восстановить открытую базу данных

Выберите «Файл» > «Информация» > «Сжать и восстановить базу данных».

Access создает копию сжатой и восстановленной базы данных в том же месте.

Вручную сжать и восстановить закрытую базу данных

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

Убедитесь, что другие пользователи в настоящее время не используют файл базы данных.

В Access 2013, Access 2016 и Access 2019:

На странице шаблонов дважды щелкните Пустая база данных.

Выберите «Файл» > «Закрыть».

Выберите Инструменты базы данных > Сжать и восстановить базу данных.

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

Access создает копию сжатой и восстановленной базы данных в том же месте.

Сжать и восстановить поврежденную базу данных при появлении соответствующего запроса

Если при попытке открыть поврежденный файл базы данных Access предложит сжать и восстановить базу данных, выберите Да. Могут произойти две вещи:

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

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

Почему следует сжимать и восстанавливать базу данных

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

Файлы базы данных увеличиваются по мере использования

По мере добавления и обновления данных и изменения их дизайна файл базы данных становится больше. Частично этот рост обусловлен новыми данными, а частично — другими источниками:

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

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

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

Файлы базы данных могут быть повреждены

В определенных обстоятельствах файл базы данных может быть поврежден. Если файл базы данных находится в общем доступе по сети и несколько пользователей одновременно работают непосредственно с файлом, существует небольшой риск повреждения этого файла. Риск повреждения несколько выше, если пользователи часто редактируют данные в полях Memo, и риск увеличивается со временем. Вы можете уменьшить этот риск, используя команду "Сжать и восстановить базу данных".

Часто этот тип повреждения возникает из-за проблемы с модулем Visual Basic для приложений (VBA) и не представляет риска потери данных. Однако этот тип повреждения создает риск повреждения структуры базы данных, например потери кода VBA или непригодных для использования форм.

В редких случаях повреждение файла базы данных приводит к потере данных. Обычно этот проигрыш ограничивается последним действием одного пользователя; то есть одно изменение данных. Когда пользователь начинает изменять данные, а изменение прерывается, например, из-за потери сетевой службы, Access помечает файл базы данных как поврежденный. Файл можно восстановить, но некоторые данные могут отсутствовать после завершения восстановления.

Это последняя, но не последняя статья в серии журналов транзакций SQL Server. В этой серии статей (см. оглавление ниже) мы описали концепцию журнала транзакций с четырех различных аспектов.

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

После этого мы рассмотрели три типа моделей восстановления: полное, простое и массовое, которые определяют, как транзакции записываются в файл журнала транзакций SQL, а также отношения между журналом транзакций SQL Server и различными типами. решений для обеспечения высокой доступности и аварийного восстановления.

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

Наконец, мы обсудили, как воспользоваться преимуществами журналов, которые автоматически записываются в журнал транзакций при отмене или повторении определенного процесса изменения данных. В этой статье мы увидим, как восстановить базу данных SQL Server с поврежденным или удаленным файлом журнала транзакций SQL Server.

Определение проблемы

При запуске службы SQL Server ядро SQL Server Engine прочитает весь файл журнала транзакций и выполнит процесс восстановления, который включает этапы повторного выполнения и отмены. В случае сбоя процесса чтения или восстановления база данных не будет переведена в оперативный режим и будет помечена как подозрительная или ожидающая восстановления в зависимости от стадии сбоя.

Повреждение файла журнала транзакций может быть вызвано несколькими причинами, включая:

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

Устранение неполадок

Если вы не можете перевести базу данных в оперативный режим, так как она застряла в состоянии SUSPECT или Recovery Pending , первое действие, которое вам нужно выполнить, — это просмотреть журналы ошибок SQL Server и журналы приложений Windows и системных событий на SQL Server, который размещает эту базу данных. Если обнаружена какая-либо проблема с оборудованием, обратитесь к системному администратору или поставщику оборудования, чтобы решить эту проблему за вас. Если проблема вызвана повреждением файла журнала транзакций, продолжайте читать эту статью, чтобы узнать, как решить эту проблему.

Вы можете обнаружить ряд ошибок, указывающих на проблему с файлом журнала транзакций SQL Server, например:

Произошла ошибка активации файла. Имя физического файла «C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\XXX.ldf» может быть неверным. Выявите и исправьте дополнительные ошибки, а затем повторите операцию.
SQL Server обнаружил ошибку ввода-вывода на основе логической согласованности: неверная контрольная сумма (ожидаемая: 0x186ba635; фактическая: 0x186b2635). Это произошло во время чтения страницы (2:0) в базе данных с идентификатором 22 по смещению 0000000000000000 в файле «C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\XXX.ldf». Дополнительные сообщения в журнале ошибок SQL Server или журнале системных событий могут содержать дополнительные сведения. Это серьезная ошибка, которая угрожает целостности базы данных и должна быть исправлена немедленно. Выполните полную проверку целостности базы данных (DBCC CHECKDB). Эта ошибка может быть вызвана многими факторами; дополнительные сведения см. в электронной документации по SQL Server
Невозможно перестроить журнал, так как при выключении базы данных были открытые транзакции/пользователи, в базе данных не было контрольной точки или база данных была доступна только для чтения. Эта ошибка может возникнуть, если файл журнала транзакций был удален вручную или потерян из-за сбоя оборудования или среды.

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

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

Разрешение

Чтобы восстановить поврежденный файл журнала транзакций SQL Server, мы должны перевести базу данных в аварийное состояние в однопользовательском режиме с помощью следующей команды:

Читайте также: