Вопрос по restore, android, sqlite, backup – Sqlite DB Android Backup / Восстановление

3

Я хотел знать, каковы лучшие методы для резервного копирования и восстановления базы данных SQLite на Android. В настоящее время я подхожу к этой проблеме, беря резервную копию БД и используя File Stream / Output Streams, чтобы скопировать ее на SD-карту. Затем я использую обратный процесс, если я хочу восстановить и старую резервную копию.

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

Спасибо

Ваш Ответ

3   ответа
4

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

Единственный другой способ сделать это - прочитать фактическое содержимое БД и сгенерировать файл, содержащий SQL, из которого он может быть восстановлен. Это, очевидно, является более сложным и не дает никаких преимуществ для оправдать эту сложность.

0

мне добавить его в качестве комментария). В подходе, который просто копирует файл, если пользователь когда-либо восстанавливает БД и в нем уже есть какие-либо данные, он будет перезаписан. Например, если пользователь обновляется до нового телефона, некоторое время использует его, а затем восстанавливает БД со своего старого телефона, все данные, уже находящиеся на новом телефоне, будут потеряны. Это одно из преимуществ сложности чтения БД и записи ее в файл (XML или CSV и т. Д.).

Я выложил еще один вопрос (Android sqlite резервное копирование / восстановление без перезаписив надежде на то, что у кого-то найдется лучшее решение, которое позволило бы избежать этой проблемы, но пока кажется, что ее нет. Между этим и проблемами, отмеченными ssuperz28, кажется, что гораздо более безопасный способ сделать резервную копию вашей БД - это записать ее в xml, а затем прочитать и добавить обратно при восстановлении.

Также,https://stackoverflow.com/a/34477622/3108762 является лучшим из других предложений, которые я видел до сих пор, и обещает лучший способ приблизиться к этому, начиная с Зефира.

17

мя я делаю это в моем приложении так же, как вы объясняете выше. Остерегайтесь при создании резервных копий таким способом. По большей части он работает отлично, но проблема в том, что созданная резервная копия не гарантированно совместима со всеми устройствами и версиями Android. Я подумал, что это звучит странно, когда я впервые услышал это, но теперь я обнаружил, что это правда. В последнее время я получаю несколько сообщений об отсутствующих данных, исчезающих данных и тому подобное. Все это происходило, когда пользователь восстанавливал резервную копию либо с другого устройства, либо с другой версии Android или ПЗУ. Несколько из них связались со мной напрямую, и это было здорово, так что я смог получить резервные файлы от них, чтобы проверить их и изучить. Когда я пытался восстановить их, я получал следующую ошибку logcat:android.database.sqlite.sqlitedatabasecorruptexception: database disk image is malformed

Что я обнаружил, так это то, что, в основном, определенные устройства HTC и некоторые пользовательские диски (на любом устройстве) создавали эти резервные копии, которые не будут восстанавливаться на других устройствах или дисках. Базы данных не были действительно повреждены, но Android думал, что они были. Я бы взял их в браузер SQLite, и там не было бы никаких данных. Оказывается, что в более новых версиях SQLite по умолчанию включена функция WAL (Write Ahead Logging), и если она включена и выполняется резервное копирование с этой базой данных, ее нельзя восстановить в более старую версию SQLite или даже иногда в ту же версию (для какая-то странная причина). Итак, я отключил WAL с помощью & quot; PRAGMA journal_mode = DELETE & quot; и тогда я смог просмотреть базу данных в браузере и восстановить ее на моем тестовом устройстве нормально. Другая проблема состоит в том, что, похоже, нет способа отловить это исключение в коде, и Android автоматически удаляет базу данных, когда сталкивается с этим исключением (на мой взгляд, очень плохое управление на Android).

Извините за длинный ответ, но я хотел объяснить, что я вижу, когда происходит такое резервное копирование. Я пытаюсь найти другой способ создания универсальной резервной копии на SD-карте. Создание CSV-файлов и SQL-скриптов, как сказал @Kingamajick, может быть другим способом сделать это. Это больше кода и больше работы, но если он работает на любом устройстве, версии SQLite и ROM, то это того стоит. Потеря ваших клиентов никогда не бывает хорошей вещью.

Вы используете транзакции в Sqlite, чтобы убедиться, что данные либо полностью, либо вообще не записаны? Arnab C.
Вот то, что я думаю, может быть хорошим решением. Что делать, если вы создаете базу данных при развертывании приложения. Таким образом, вы узнаете, какой режим журнала используется при развертывании, и вам не придется беспокоиться об этом позже. Я полагаю, вы могли бы обновить существующую базу данных и выполнить команду rawsql, чтобы сохранить Pragma journal_mode = Delete. Дайте мне знать, если вы думаете, что я что-то здесь упускаю. Спасибо Arnab C.
Можете ли вы указать, в каких выпусках API вы обнаружили проблемы. Thx Arnab C.
Да, я использую транзакции. Данные находятся в резервной копии, их можно просмотреть в браузере SQLite, который включает в себя новейшую версию SQLite, или в браузере, который включает в себя более старую версию, если вы установили «PRAGMA journal_mode = DELETE».
Это происходило на устройствах HTC под управлением Android 2.3. Я также видел это на дисках CM7 и CM9. Однако это не все устройства HTC, особенно серия Desire. Очевидно, что на этих устройствах HTC и Cyanogemod включена функция WAL по умолчанию в SQLite, и они не очень хорошо работают с другими версиями, устройствами или версиями SQLite. Я думаю, что по мере того, как все больше устройств получат ICS и более новую версию SQLite, эти старые резервные копии, созданные на устройствах до 4.0, начнут создавать проблемы при восстановлении. Я не видел каких-либо исключений, подобных этому, до выпуска 2.3.3+ и удаления других устройств от FROYO.

Похожие вопросы