Базовое повреждение Хранилища данных
Горстка клиентов для моего приложения для iPhone испытывает Базовое повреждение Хранилища данных (я принимаю так, так как ошибка является "Отказавшей для сохранения к хранилищу данных: Операция не могла быть завершена. (Ошибка какао 259.)")
Кто-либо еще испытал этот вид повреждения хранилища? Я волнуюсь, так как я стремлюсь скоро продвигать обновление, которое выполняет миграцию схемы, и я волнуюсь, что это выставит еще больше проблем.
Я предположил, что Базовые API Data/SQLlite используют атомарные операции и неуязвимы для повреждения кроме того, если базовая файловая система испытывает повреждение.
Есть ли способ уменьшить/предотвратить повреждение и способ воспроизвести повреждение, таким образом, я могу протестировать это (я был неудачен к настоящему времени).
Править:
Также получение этой ошибки: "База данных в/var/mobile/Applications//Documents/foo.sqlite повреждается. Код ошибки SQLite 11, образ диска базы данных уродлив".
4 ответа
Ошибка, которую вы получаете, определена в Foundation.h
NSFileReadCorruptFileError = 259, // Ошибка чтения (файл поврежден, неправильный формат и т. Д.)
Я никогда не сталкивался с этим в реальном магазине, но я обнаружил нечто подобное с плохими разрешениями (на Mac). Я также не видел, чтобы кто-нибудь упоминал подобную ошибку в Интернете. Системы предотвращения ошибок в Core Data довольно надежны.
Я полагаю, что самый простой способ создать это - отправить постоянное хранилище для просмотра неправильного файла, например, случайно нацелив его на текстовый файл. Если он ожидает хранилище SQL, но найдет что-то еще, он пожалуется, что файл поврежден. Это просто выстрел в темноте.
Редактировать
Это будет сложно отследить, потому что подобные ошибки настолько редки в Core Data, что нет никаких инструментов, помогающих найти проблему.
Я бы порекомендовал:
- Проверить исходный код ошибки, исходящей из кода. Возможно, что-то сбивает магазин или заставляет его искать в другом месте.
- Проверяйте везде, где вы могли бы сделать что-то нестандартное. Например, если вы создаете свою собственную карту сущностей в коде, ее легко отбросить, если вы не будете осторожны.
Также попытайтесь воспроизвести ошибку, заполнив диск на Устройстве - вы должны получить ошибку переполнения диска вместо повреждения базы данных, но таким образом можно получить поврежденную базу данных.
Вы когда-нибудь взаимодействовали с базой данных, используя sqlite API? Или вы использовали какие-либо инструменты сторонних производителей для создания своей исходной базы данных?
Я недавно столкнулся с этой проблемой. В моем случае я выполнял поиск и перебирал объекты для преобразования данных в XML и KML. Затем я бы запустил обработчик электронной почты и прикрепил файлы. Затем я обновлял поле в объектах и, наконец, сохранял в резервном хранилище (SQL Lite). Работал нормально в 3.х. В 4.x сломалось.
С моей стороны было глупо выполнять всю обработку электронной почты до изменения и сохранения БД. Перемещение всего несущественного кода в точку после сохранения устранило эту проблему.
Эта проблема может полностью повредить базу данных SQL. В моем случае ошибка:
File at path does not appear to be a SQLite database