<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-49A3419F-D20A-5C5D-B2FF-51724EF37704" xml:lang="en"><title>Prevent

Database File Corruption</title><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>This guide describes how databases might be corrupted. </p>

<section id="GUID-5C9649BC-EB5A-4528-87AA-ECAB64D62467"><title>Introduction</title> <p>Although SQLite is very resistant

to database corruption, thanks to the atomic features, it is still possible

for a database file to become corrupt. By understanding the known ways of

corrupting a SQLite database, you can make sure you avoid them. </p> <p><b>Intended

audience:</b> </p> <p>This document is intended to be used by Symbian platform

licensees and third party application developers. </p> </section>

<section id="GUID-E921DD90-259E-5843-80FF-C5D85BB7545C"><title>Avoid Corrupting

your Database Files</title> <p>One of the key benefits of using an atomic

and durable database engine is that you can be responsibly confident that

the database will not be corrupted by application crashes or power failures.

SQLite is very resistant to database corruption but it is possible to corrupt

a database. This section will describe all of the known techniques for corrupting

a SQLite database so that you can make sure you avoid them. </p> <p>The following

database corruption situations will be discussed here: </p> <ul>

<li id="GUID-952C9192-E349-5B34-860C-A19B874BFC0F"><p>Hardware failure --

beyond the control of SQLite </p> </li>

<li id="GUID-55D027FD-912D-5114-8E85-2AEC56CCBC4E"><p>System Crash -- when

rollback journal exists </p> </li>

<li id="GUID-7070E8B3-C218-5E6F-AAAB-7EE4479C196E"><p>post crash application

recovery </p> </li>

<li id="GUID-5D2454C9-075B-5A15-B736-94F1E9188D03"><p>hot journal name conflict </p> </li>

</ul> <p>A SQLite database is just an ordinary file in the file system. If

the database is placed in a publicly accessible location then any process

can open that file and write nonsense into the middle of it, corrupting the

database. Similarly, an operating system malfunction or a hardware fault can

cause invalid data to be written into the database file. Both of these issues

are beyond the control of SQLite or of application developers. We only mention

them here for completeness. </p> <p>After a power loss or system crash and

subsequent system reboot, a rollback journal file will be found in the same

directory as the original database. The presence of this rollback journal

file is the signal to subsequent users that the database is in an inconsistent

state and needs to be restored (by playing back the journal) before it is

used. A rollback journal file that is left over after a crash is called a

“hot journal”. </p> <p>If after a post-crash reboot some kind application

recovery occurs which deletes, renames, or moves a hot journal, then SQLite

will have no way of knowing that a hot journal existed. It will not know that

the database is in an inconsistent state and will have no way to restore it.

Deleting or renaming a hot journal will result in a corrupted database nearly

every time. </p> <p>The name of the hot journal is related to the name of

the original database file. If the database file is renamed this means that

SQLite will not see the hot journal based on the original name, no database

recovery will be undertaken and the database will become corrupt. </p> <p>These

are all of the known ways for corrupting a SQLite database file, and as you

can see, none of these ways are easy to achieve. SQLite databases have proven

to be remarkably reliable and trouble-free. By avoiding the above situations

you can ensure that your databases will be safe and intact even after system

crashes and untimely power failures. </p> </section>

</conbody><related-links>

<link href="GUID-22844C28-AB5B-5A6F-8863-7269464684B4.dita"><linktext>SQL Overview</linktext>

</link>

<link href="GUID-78773BCA-ADF6-53E6-AC80-5CB2AE1F8BCC.dita"><linktext>SQL Server

Guide</linktext></link>

<link href="GUID-E51836E1-D33E-506C-B75B-19B8E3CC313A.dita"><linktext>SQLite</linktext>

</link>

<link href="GUID-1F12E3F5-45B2-55EC-B021-00338277C608.dita"><linktext>SQL DB Overview</linktext>

</link>

<link href="GUID-43CA02E7-0101-5824-B91B-E15EE20C829A.dita"><linktext>Avoid Transient

Tables</linktext></link>

<link href="GUID-C2FAEBB2-4A1A-5BB0-9670-4801525CBC6A.dita"><linktext>SQL Index

Tips</linktext></link>

<link href="GUID-B994E6F7-228A-5433-B87F-91857C5D93D6.dita"><linktext>SQL Insertion

Tips</linktext></link>

<link href="GUID-4FC23DB7-4758-5DA4-81FF-0DAB169E2757.dita"><linktext>SQL Schema

Tips</linktext></link>

<link href="GUID-2A2920E0-5D40-5358-BC0C-8572CEFE078C.dita"><linktext>SQL Expressions</linktext>

</link>

<link href="GUID-126FCCCC-0E7D-59AE-959A-2F94A7319C4B.dita"><linktext>SQL Statement

Tips</linktext></link>

<link href="GUID-ACCCB148-DAF9-59EC-B585-8EF632B9BF04.dita"><linktext>SQL Joins</linktext>

</link>

<link href="GUID-B7E978C1-45CA-554C-8028-D901B97BA2E0.dita"><linktext> ANALYZE

Command</linktext></link>

<link href="GUID-AF5A75D7-0687-546C-87B2-0B7DF7D33217.dita"><linktext> SQL WHERE

CLause Tips</linktext></link>

</related-links></concept>