39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
-
-
-
+
+
+
-
-
-
+
+
+
-
-
-
+
+
+
-
+
-
-
-
-
+
+
+
+
-
-
-
+
+
+
-
-
-
+
+
+
-
+
-
-
+
+
-
-
-
-
-
-
-
+
+
+
+
+
+
+
|
</td>
</tr>
</table>
</div>
<div id="mainSection">
<div id="mainBody">
<h1 class="heading">Limitations of this ADO.NET SQLite Data Provider</h1>
<p>As providers go, this one doesn't have many restrictions. SQLite has no
support for row-level or table-level locks. When a connection locks the database for writing, no other connection or process may read or write to the database until the write operation is complete. The SQLite.NET provider attempts to retry
internally if a database is locked, up to the CommandTimeout property of the
<p>As providers go, this one doesn't have many restrictions. SQLite has no
support for row-level or table-level locks. When a connection locks the database for writing, no other connection or process may read or write to the database until the write operation is complete. The SQLite.NET provider attempts to retry
internally if a database is locked, up to the CommandTimeout property of the
command in question.</p>
<p>SQLite is inherently type-less, and only understands a few basic datatypes
natively. They are (in .NET-speak) Int64, Double, String and Blob. The
SQLite.NET provider will use the database schema information it can glean to
<p>SQLite is inherently type-less, and only understands a few basic datatypes
natively. They are (in .NET-speak) Int64, Double, String and Blob. The
SQLite.NET provider will use the database schema information it can glean to
enforce type-ness, but it is an inexact science.</p>
<p>
Hierarchical DataReaders are not supported. In the
case of transactions, any SQLiteCommand created on a connection will (when
executed) automatically join a transaction in progress, regardless of whether
Hierarchical DataReaders are not supported. In the
case of transactions, any SQLiteCommand created on a connection will (when
executed) automatically join a transaction in progress, regardless of whether
that transaction was created before or after the command.</p>
<p>A SQLiteCommand object <b>can</b> be re-assigned a new SQLiteConnection object
<p>A SQLiteCommand object <b>can</b> be re-assigned a new SQLiteConnection object
as long as no DataReaders are active on the command.</p>
<p>Opening a transaction is considered a write operation, so only use them when
you want to write to the database! If you hold open a transaction, all readers on other
connections
will be blocked until the transaction is closed!</p>
<p>Opening a transaction is considered a write operation, so only use them when
you want to write to the database! If you hold open an "immediate"
transaction, all readers on other connections will be blocked until the
transaction is closed!</p>
<p></p>
<h4 class="subHeading">Thread Safety</h4>
<p>Multi-threading in SQLite must be done carefully. Here are the restrictions:</p>
<ul>
<li>
<b>You May</b>
Clone() a SQLiteConnection object in one thread and pass the cloned object to
another thread. Once passed, the other thread becomes the new owner of the
cloned connection, and the original thread must not keep a reference to the
Clone() a SQLiteConnection object in one thread and pass the cloned object to
another thread. Once passed, the other thread becomes the new owner of the
cloned connection, and the original thread must not keep a reference to the
clone or call any methods on the clone.
<LI>
<STRONG>You May</STRONG>
create multiple threads, and those threads can create their own
SQLiteConnection and subsequent objects for accessing a database.
Multiple connections on multiple threads to the same database file are
create multiple threads, and those threads can create their own
SQLiteConnection and subsequent objects for accessing a database.
Multiple connections on multiple threads to the same database file are
perfectly acceptable and will behave predictably.
<li>
<b>You May NOT</b>
call methods or properties or otherwise reference any SQLite provider classes
call methods or properties or otherwise reference any SQLite provider classes
that belong to another thread.
<li>
<b>You May NOT</b> pass a SQLiteCommand, SQLiteDataReader, SQLiteDataAdapter or
any other SQLite provider class except a cloned SQLiteConnection to another
<b>You May NOT</b> pass a SQLiteCommand, SQLiteDataReader, SQLiteDataAdapter or
any other SQLite provider class except a cloned SQLiteConnection to another
thread.</li>
</ul>
<p>Understand again that SQLite has no fine-grained locking mechanisms. It is
therefore your own responsibility in a multi-threaded environment to handle
potential timeouts that may occur if a long-running query in one thread
prevents a query in another thread from executing. These timeouts will only
occur if one thread is attempting to read while another thread is attempting to
write. Whichever thread got its lock first will be the one to execute, and the
other thread will block until the CommandTimeout value elapses or the other
<p>Understand again that SQLite has no fine-grained locking mechanisms. It is
therefore your own responsibility in a multi-threaded environment to handle
potential timeouts that may occur if a long-running query in one thread
prevents a query in another thread from executing. These timeouts will only
occur if one thread is attempting to read while another thread is attempting to
write. Whichever thread got its lock first will be the one to execute, and the
other thread will block until the CommandTimeout value elapses or the other
thread finishes.</p>
<hr/>
<div id="footer">
<p>
<a href="mailto:sqlite-users@sqlite.org?subject=SQLite.NET%20Class%20Library%20Documentation%20Feedback:%20Limitations">
Send comments on this topic.</a>
</p>
|