#iphone #sqlite
#iPhone #sqlite
Вопрос:
Недавно я внедрил компонент кэша в свое приложение для iPhone, которое использует SQLite. Я записываю и считываю данные изначально без какой-либо среды-оболочки. Проблема в том, что после некоторого использования приложения оно начинает получать код состояния SQLITE_CORRUPT в ответ на любое SQL-утверждение, которое я выполняю в БД.
Я использую SQLiteManager в качестве моего инструмента mgmt DB. Когда база данных повреждена, я пытаюсь анализировать и проверять через SQLiteManager, но это даже не позволяет мне просматривать данные в таблице и просто выдает лаконичное сообщение о том, что данные повреждены.
Кто-нибудь может помочь с этим? Во-первых, как, черт возьми, БД попадает в эту ситуацию, а во-вторых, как или где я могу увидеть данные в любом случае?
Спасибо, парень.
Комментарии:
1. Вам придется опубликовать имеющийся у вас код, который обрабатывает кэширование, если вы хотите, чтобы кто-нибудь смог вам помочь. Но есть ли веская причина не использовать NSUserDefaults для того, что вы делаете? Или даже просто сохранение файла plist в каталоге docs приложения? Не знаю, что вы подразумеваете под «компонентом кэша», но sql — это проблема в использовании, если вам действительно не нужно (и когда вам нужно, я бы использовал Core Data вместо прямого обращения к SQL).
2. Спасибо за ваш комментарий @CharlieMezak. plist и NSUserDefaults недостаточно хороши для меня, потому что мне нужен более сложный механизм, чем просто сохранение записей key value. Я проверил Core Data, но мне действительно не нужно моделировать мои объекты и реализовывать O R mapping, поэтому он также не подходит. У меня остался только собственный SQL…
3. Возможно, вам не понадобятся некоторые функции Core Data, но, по крайней мере, вам не придется беспокоиться о том, чтобы работать с SQL напрямую. Я бы пропустил сразу оболочку SQL и сразу перешел к core data. Он чистый, простой и обладает функциями более высокого уровня, если вы когда-нибудь обнаружите, что они вам нужны.
4. Я провел некоторый рефакторинг существующего кода в своем приложении. Если это не исправит ситуацию — я перейду на Core Data.
Ответ №1:
Вы можете обратиться к этой официальной документации. Здесь они упомянули, что вероятность повреждения базы данных очень мала.
Они также указали шансы того, как может быть повреждена база данных. И оттуда обратитесь к следующему примеру, который может вызвать проблему с базой данных.
CREATE TABLE ex1(a INTEGER PRIMARY KEY, b);
INSERT INTO ex1 VALUES(1,2);
INSERT INTO ex1 VALUES(2,3);
CREATE TRIGGER ex1_tr1 AFTER UPDATE ON ex1 BEGIN
DELETE FROM ex1 WHERE a=old.b;
END;
UPDATE ex1 SET b=b 1;
В приведенном выше примере первый цикл ОБНОВЛЕНИЯ приводит к срабатыванию триггера и удалению второй строки таблицы ex1. Когда выполняется второй цикл цикла ОБНОВЛЕНИЯ, он пытается обработать вторую строку таблицы ex1. SQLite распознал, что вторая строка была удалена, поэтому он прерывает второй цикл, но ему не удалось выполнить очистку после себя должным образом, что могло привести к повреждению базы данных в последующих циклах цикла.
Итак, в основном вам нужно выяснить ситуацию, когда это произошло в вашем коде, путем отладки или путем выполнения шагов через ваше приложение или любой другой механизм.
Комментарии:
1. Спасибо за ссылку! Просмотрел ссылку и обнаружил, что предложение REPLACE INTO может привести к повреждению.. Я заменяю REPLACE на «примитивное» обновление и вставляю. Будет обновлено, если это сработало.
2. @Ребята, с удовольствием. Был бы рад, если это сработает у вас. И если он примет ответ или проголосует за ответ. Спасибо.
3. @ Ребята, вы нашли решение для повреждения sqlite? потому что я тоже сталкиваюсь с этой проблемой.