diff -r 48780e181b38 -r 578be2adaf3e Symbian3/PDK/Source/GUID-A278C1A2-0724-5800-B353-46809C44C142.dita
--- a/Symbian3/PDK/Source/GUID-A278C1A2-0724-5800-B353-46809C44C142.dita	Tue Jul 20 12:00:49 2010 +0100
+++ b/Symbian3/PDK/Source/GUID-A278C1A2-0724-5800-B353-46809C44C142.dita	Fri Aug 13 16:47:46 2010 +0100
@@ -1,52 +1,52 @@
-<?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-A278C1A2-0724-5800-B353-46809C44C142" xml:lang="en"><title>Transactions
-on store databases</title><shortdesc>Atomicity of updates, roll backs, and what happens to indexes when
-a rollback happens are covered in this document.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>The store database, <codeph>RDbStoreDatabase</codeph>, runs completely
-client side and requires the user program to provide a store for its operations.
-For this reason, isolation, concurrency and serializability are not issues
-for the transaction model. However, support for multiple rowsets concurrently
-updating the same table is provided, and the rowset cursors attempt to maintain
-their current position through such (potentially conflicting) updates.</p>
-<p>Transactions on a store database do guarantee atomicity of updates. As <codeph>RDbStoreDatabase</codeph> is
-designed to be a small-scale relational database, it does not make sense for
-it to use transaction systems more suited to large server hosted databases.
-Instead of using a logfile, the store database provides transaction support
-by using the commit and revert functionality of <codeph>CStreamStore</codeph>.
-If the actual store class does not support this protocol, then it cannot be
-used as a basis for a DBMS store database. Practically, this means that store
-databases are permanent file stores, i.e. <codeph>CPermanentFileStore</codeph>.</p>
-<p>Successful transaction support by <codeph>RDbStoreDatabase</codeph> requires
-that <i>the client must not call </i> <codeph>CommitL()</codeph> <i> and </i> <codeph>Revert()</codeph> <i> on
-the store while the database is open</i>. Should a client need to modify its
-own stream data using the store's commit/revert protocol while a database
-is open, it can enclose the stream operations within a database transaction,
-using rollback on error; this achieves an equivalent result. Such store operations
-can be combined with database updates within a transaction to ensure that
-the separate updates are treated atomically.</p>
-<p>Committing a transaction leaves all open rowsets in a valid state. How
-and when updates are reflected within those rowsets depends on how they have
-been evaluated. </p>
-<p>Rolling back a transaction causes all rowsets on the database to lose their
-current place. All rowsets must be reset and possibly be re-evaluated before
-they can be used again. However, they do not need to be opened or prepared
-again.</p>
-<p>Indexes cannot be recovered easily on rollback, so they are marked as unusable,
-and the database is marked as damaged. Tables and untouched indexes continue
-to operate as before. Recovering the database restores the damaged indexes
-fully. </p>
-<p>For multiple updates, explicitly using a transaction can also reduce the
-time required by a factor of more than 50. It also reduces the transient store
-size requirement by a factor of more than 6 — compaction of the store results
-in similar sizes for updates whether or not a transaction was used.</p>
+<?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-A278C1A2-0724-5800-B353-46809C44C142" xml:lang="en"><title>Transactions
+on store databases</title><shortdesc>Atomicity of updates, roll backs, and what happens to indexes when
+a rollback happens are covered in this document.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>The store database, <codeph>RDbStoreDatabase</codeph>, runs completely
+client side and requires the user program to provide a store for its operations.
+For this reason, isolation, concurrency and serializability are not issues
+for the transaction model. However, support for multiple rowsets concurrently
+updating the same table is provided, and the rowset cursors attempt to maintain
+their current position through such (potentially conflicting) updates.</p>
+<p>Transactions on a store database do guarantee atomicity of updates. As <codeph>RDbStoreDatabase</codeph> is
+designed to be a small-scale relational database, it does not make sense for
+it to use transaction systems more suited to large server hosted databases.
+Instead of using a logfile, the store database provides transaction support
+by using the commit and revert functionality of <codeph>CStreamStore</codeph>.
+If the actual store class does not support this protocol, then it cannot be
+used as a basis for a DBMS store database. Practically, this means that store
+databases are permanent file stores, i.e. <codeph>CPermanentFileStore</codeph>.</p>
+<p>Successful transaction support by <codeph>RDbStoreDatabase</codeph> requires
+that <i>the client must not call </i> <codeph>CommitL()</codeph> <i> and </i> <codeph>Revert()</codeph> <i> on
+the store while the database is open</i>. Should a client need to modify its
+own stream data using the store's commit/revert protocol while a database
+is open, it can enclose the stream operations within a database transaction,
+using rollback on error; this achieves an equivalent result. Such store operations
+can be combined with database updates within a transaction to ensure that
+the separate updates are treated atomically.</p>
+<p>Committing a transaction leaves all open rowsets in a valid state. How
+and when updates are reflected within those rowsets depends on how they have
+been evaluated. </p>
+<p>Rolling back a transaction causes all rowsets on the database to lose their
+current place. All rowsets must be reset and possibly be re-evaluated before
+they can be used again. However, they do not need to be opened or prepared
+again.</p>
+<p>Indexes cannot be recovered easily on rollback, so they are marked as unusable,
+and the database is marked as damaged. Tables and untouched indexes continue
+to operate as before. Recovering the database restores the damaged indexes
+fully. </p>
+<p>For multiple updates, explicitly using a transaction can also reduce the
+time required by a factor of more than 50. It also reduces the transient store
+size requirement by a factor of more than 6 — compaction of the store results
+in similar sizes for updates whether or not a transaction was used.</p>
 </conbody></concept>
\ No newline at end of file