SQLiteDatabase

When a constraint violation occurs,no ROLLBACK is executed so changes from prior commands within the same transaction are preserved. This is the default behavior.

When a constraint violation occurs, the command aborts with a return code SQLITE_CONSTRAINT. But any changes to the database that the command made prior to encountering the constraint violation are preserved and are not backed out.

When a constraint violation occurs, the one row that contains the constraint violation is not inserted or changed. But the command continues executing normally. Other rows before and after the row that contained the constraint violation continue to be inserted or updated normally. No error is returned.

Use the following when no conflict action is specified.

When a UNIQUE constraint violation occurs, the pre-existing rows that are causing the constraint violation are removed prior to inserting or updating the current row. Thus the insert or update always occurs. The command continues executing normally. No error is returned. If a NOT NULL constraint violation occurs, the NULL value is replaced by the default value for that column. If the column has no default value, then the ABORT algorithm is used. If a CHECK constraint violation occurs then the IGNORE algorithm is used. When this conflict resolution strategy deletes rows in order to satisfy a constraint, it does not invoke delete triggers on those rows. This behavior might change in a future release.

When a constraint violation occurs, an immediate ROLLBACK occurs, thus ending the current transaction, and the command aborts with a return code of SQLITE_CONSTRAINT. If no transaction is active (other than the implied transaction that is created on every command) then this algorithm works the same as ABORT.

Open flag: Flag for openDatabase(String, SQLiteDatabase.CursorFactory, int) to create the database file if it does not already exist.

Open flag: Flag for openDatabase(String, SQLiteDatabase.CursorFactory, int) to open the database file with write-ahead logging enabled by default. Using this flag is more efficient than calling enableWriteAheadLogging() . Write-ahead logging cannot be used with read-only databases so the value of this flag is ignored if the database is opened read-only.

Absolute max value that can be set by setMaxSqlCacheSize(int) . Each prepared-statement is between 1K - 6K, depending on the complexity of the SQL statement & schema. A large SQL cache may use a significant amount of memory.

Open flag: Flag for openDatabase(String, SQLiteDatabase.CursorFactory, int) to open the database without support for localized collators.

This causes the collator LOCALIZED not to be created. You must be consistent when using this flag to use the setting the database was created with. If this is set, setLocale(Locale) will do nothing.

Open flag: Flag for openDatabase(String, SQLiteDatabase.CursorFactory, int) to open the database for reading only. This is the only reliable way to open a database if the disk may be full.

Open flag: Flag for openDatabase(String, SQLiteDatabase.CursorFactory, int) to open the database for reading and writing. If the disk is full, this may fail even before you actually write anything.

Note that the value of this flag is 0, so it is the default.

Maximum Length Of A LIKE Or GLOB Pattern The pattern matching algorithm used in the default LIKE and GLOB implementation of SQLite can exhibit O(N^2) performance (where N is the number of characters in the pattern) for certain pathological cases. To avoid denial-of-service attacks the length of the LIKE or GLOB pattern is limited to SQLITE_MAX_LIKE_PATTERN_LENGTH bytes. The default value of this limit is 50000. A modern workstation can evaluate even a pathological LIKE or GLOB pattern of 50000 bytes relatively quickly. The denial of service problem only comes into play when the pattern length gets into millions of bytes. Nevertheless, since most useful LIKE or GLOB patterns are at most a few dozen bytes in length, paranoid application developers may want to reduce this parameter to something in the range of a few hundred if they know that external users are able to generate arbitrary patterns.

Begins a transaction in EXCLUSIVE mode.

Transactions can be nested. When the outer transaction is ended all of the work done in that transaction and all of the nested transactions will be committed or rolled back. The changes will be rolled back if any transaction is ended without being marked as clean (by calling setTransactionSuccessful). Otherwise they will be committed.

Here is the standard idiom for transactions:

          db.beginTransaction();
   try {
     ...
     db.setTransactionSuccessful();
   } finally {
     db.endTransaction();
   }
         

Begins a transaction in IMMEDIATE mode. Transactions can be nested. When the outer transaction is ended all of the work done in that transaction and all of the nested transactions will be committed or rolled back. The changes will be rolled back if any transaction is ended without being marked as clean (by calling setTransactionSuccessful). Otherwise they will be committed.

Here is the standard idiom for transactions:

          db.beginTransactionNonExclusive();
   try {
     ...
     db.setTransactionSuccessful();
   } finally {
     db.endTransaction();
   }
         

Begins a transaction in EXCLUSIVE mode.

Transactions can be nested. When the outer transaction is ended all of the work done in that transaction and all of the nested transactions will be committed or rolled back. The changes will be rolled back if any transaction is ended without being marked as clean (by calling setTransactionSuccessful). Otherwise they will be committed.

Here is the standard idiom for transactions:

          db.beginTransactionWithListener(listener);
   try {
     ...
     db.setTransactionSuccessful();
   } finally {
     db.endTransaction();
   }
         

Begins a transaction in IMMEDIATE mode. Transactions can be nested. When the outer transaction is ended all of the work done in that transaction and all of the nested transactions will be committed or rolled back. The changes will be rolled back if any transaction is ended without being marked as clean (by calling setTransactionSuccessful). Otherwise they will be committed.

Here is the standard idiom for transactions:

          db.beginTransactionWithListenerNonExclusive(listener);
   try {
     ...
     db.setTransactionSuccessful();
   } finally {
     db.endTransaction();
   }
         

Compiles an SQL statement into a reusable pre-compiled statement object. The parameters are identical to execSQL(String) . You may put ?s in the statement and fill in those values with bindString(int, String) and bindLong(int, long) each time you want to run the statement. Statements may not return result sets larger than 1x1.

No two threads should be using the same SQLiteStatement at the same time.

Create a memory backed SQLite database. Its contents will be destroyed when the database is closed.

Sets the locale of the database to the the system's current locale. Call setLocale(Locale) if you would like something else.

Convenience method for deleting rows in the database.

Deletes a database including its journal file and other auxiliary files that may have been created by the database engine.

This method disables the features enabled by enableWriteAheadLogging() .

This method enables parallel execution of queries from multiple threads on the same database. It does this by opening multiple connections to the database and using a different database connection for each query. The database journal mode is also changed to enable writes to proceed concurrently with reads.

When write-ahead logging is not enabled (the default), it is not possible for reads and writes to occur on the database at the same time. Before modifying the database, the writer implicitly acquires an exclusive lock on the database which prevents readers from accessing the database until the write is completed.

In contrast, when write-ahead logging is enabled (by calling this method), write operations occur in a separate log file which allows reads to proceed concurrently. While a write is in progress, readers on other threads will perceive the state of the database as it was before the write began. When the write completes, readers on other threads will then perceive the new state of the database.

It is a good idea to enable write-ahead logging whenever a database will be concurrently accessed and modified by multiple threads at the same time. However, write-ahead logging uses significantly more memory than ordinary journaling because there are multiple connections to the same database. So if a database will only be used by a single thread, or if optimizing concurrency is not very important, then write-ahead logging should be disabled.

After calling this method, execution of queries in parallel is enabled as long as the database remains open. To disable execution of queries in parallel, either call disableWriteAheadLogging() or close the database and reopen it.

The maximum number of connections used to execute queries in parallel is dependent upon the device memory and possibly other properties.

If a query is part of a transaction, then it is executed on the same database handle the transaction was begun.

Writers should use beginTransactionNonExclusive() or beginTransactionWithListenerNonExclusive(SQLiteTransactionListener) to start a transaction. Non-exclusive mode allows database file to be in readable by other threads executing queries.

If the database has any attached databases, then execution of queries in parallel is NOT possible. Likewise, write-ahead logging is not supported for read-only databases or memory databases. In such cases, enableWriteAheadLogging() returns false.

The best way to enable write-ahead logging is to pass the ENABLE_WRITE_AHEAD_LOGGING flag to openDatabase(String, SQLiteDatabase.CursorFactory, int) . This is more efficient than calling enableWriteAheadLogging() .

          SQLiteDatabase db = SQLiteDatabase.openDatabase("db_filename", cursorFactory,
             SQLiteDatabase.CREATE_IF_NECESSARY | SQLiteDatabase.ENABLE_WRITE_AHEAD_LOGGING,
             myDatabaseErrorHandler);
     db.enableWriteAheadLogging();
         

Another way to enable write-ahead logging is to call enableWriteAheadLogging() after opening the database.

          SQLiteDatabase db = SQLiteDatabase.openDatabase("db_filename", cursorFactory,
             SQLiteDatabase.CREATE_IF_NECESSARY, myDatabaseErrorHandler);
     db.enableWriteAheadLogging();
         

See also SQLite Write-Ahead Logging for more details about how write-ahead logging works.

End a transaction. See beginTransaction for notes about how to use this and when transactions are committed and rolled back.

Execute a single SQL statement that is NOT a SELECT or any other SQL statement that returns data.

It has no means to return any data (such as the number of affected rows). Instead, you're encouraged to use insert(String, String, ContentValues) , update(String, ContentValues, String, String[]) , et al, when possible.

When using enableWriteAheadLogging() , journal_mode is automatically managed by this class. So, do not set journal_mode using "PRAGMA journal_mode' " statement if your app is using enableWriteAheadLogging()

Execute a single SQL statement that is NOT a SELECT/INSERT/UPDATE/DELETE.

For INSERT statements, use any of the following instead.

• insert(String, String, ContentValues)
• insertOrThrow(String, String, ContentValues)
• insertWithOnConflict(String, String, ContentValues, int)

For UPDATE statements, use any of the following instead.

• update(String, ContentValues, String, String[])
• updateWithOnConflict(String, ContentValues, String, String[], int)

For DELETE statements, use any of the following instead.

• delete(String, String, String[])

For example, the following are good candidates for using this method:

• ALTER TABLE
• CREATE or DROP table / trigger / view / index / virtual table
• REINDEX
• RELEASE
• SAVEPOINT
• PRAGMA that returns no data

When using enableWriteAheadLogging() , journal_mode is automatically managed by this class. So, do not set journal_mode using "PRAGMA journal_mode' " statement if your app is using enableWriteAheadLogging()

Finds the name of the first table, which is editable.

Returns list of full pathnames of all attached databases including the main database by executing 'pragma database_list' on the database.

Returns the maximum size the database may grow to.

Returns the current database page size, in bytes.

Gets the path to the database file.

Deprecated.

Gets the database version.

Returns true if the current thread has a transaction pending.

Convenience method for inserting a row into the database.

Convenience method for inserting a row into the database.

General method for inserting a row into the database.

Runs 'pragma integrity_check' on the given database (and all the attached databases) and returns true if the given database (and all its attached databases) pass integrity_check, false otherwise.

If the result is false, then this method logs the errors reported by the integrity_check command execution.

Note that 'pragma integrity_check' on a database can take a long time.

Returns true if the current thread is holding an active connection to the database.

The name of this method comes from a time when having an active connection to the database meant that the thread was holding an actual lock on the database. Nowadays, there is no longer a true "database lock" although threads may block if they cannot acquire a database connection to perform a particular operation.

Always returns false.

There is no longer the concept of a database lock, so this method always returns false.

Returns true if the database is currently open.

Returns true if the database is opened as read only.

Returns true if write-ahead logging has been enabled for this database.

Mark this table as syncable, with the _sync_dirty residing in another table. When an update occurs in this table the _sync_dirty field of the row in updateTable with the _id in foreignKey will be set to ensure proper syncing operation.

Mark this table as syncable. When an update occurs in this table the _sync_dirty field will be set to ensure proper syncing operation.

Returns true if the new version code is greater than the current database version.

Open the database according to the flags OPEN_READWRITE OPEN_READONLY CREATE_IF_NECESSARY and/or NO_LOCALIZED_COLLATORS .

Sets the locale of the database to the the system's current locale. Call setLocale(Locale) if you would like something else.

Accepts input param: a concrete instance of DatabaseErrorHandler to be used to handle corruption when sqlite reports database corruption.

Open the database according to the flags OPEN_READWRITE OPEN_READONLY CREATE_IF_NECESSARY and/or NO_LOCALIZED_COLLATORS .

Sets the locale of the database to the the system's current locale. Call setLocale(Locale) if you would like something else.

Equivalent to openDatabase(path, factory, CREATE_IF_NECESSARY, errorHandler).

Equivalent to openDatabase(path, factory, CREATE_IF_NECESSARY).

Equivalent to openDatabase(file.getPath(), factory, CREATE_IF_NECESSARY).

Query the given table, returning a Cursor over the result set.

Query the given URL, returning a Cursor over the result set.

Query the given table, returning a Cursor over the result set.

Query the given URL, returning a Cursor over the result set.

Query the given URL, returning a Cursor over the result set.

Query the given URL, returning a Cursor over the result set.

Runs the provided SQL and returns a Cursor over the result set.

Runs the provided SQL and returns a Cursor over the result set.

Runs the provided SQL and returns a cursor over the result set.

Runs the provided SQL and returns a cursor over the result set.

Attempts to release memory that SQLite holds but does not require to operate properly. Typically this memory will come from the page cache.

Convenience method for replacing a row in the database.

Convenience method for replacing a row in the database.

Sets whether foreign key constraints are enabled for the database.

By default, foreign key constraints are not enforced by the database. This method allows an application to enable foreign key constraints. It must be called each time the database is opened to ensure that foreign key constraints are enabled for the session.

A good time to call this method is right after calling openOrCreateDatabase(File, SQLiteDatabase.CursorFactory) or in the onConfigure(SQLiteDatabase) callback.

When foreign key constraints are disabled, the database does not check whether changes to the database will violate foreign key constraints. Likewise, when foreign key constraints are disabled, the database will not execute cascade delete or update triggers. As a result, it is possible for the database state to become inconsistent. To perform a database integrity check, call isDatabaseIntegrityOk() .

This method must not be called while a transaction is in progress.

See also SQLite Foreign Key Constraints for more details about foreign key constraint support.

Sets the locale for this database. Does nothing if this database has the NO_LOCALIZED_COLLATORS flag set or was opened read only.

Control whether or not the SQLiteDatabase is made thread-safe by using locks around critical sections. This is pretty expensive, so if you know that your DB will only be used by a single thread then you should set this to false. The default is true.

Sets the maximum size of the prepared-statement cache for this database. (size of the cache = number of compiled-sql-statements stored in the cache).

Maximum cache size can ONLY be increased from its current size (default = 10). If this method is called with smaller size than the current maximum value, then IllegalStateException is thrown.

This method is thread-safe.

Sets the maximum size the database will grow to. The maximum size cannot be set below the current size.

Sets the database page size. The page size must be a power of two. This method does not work if any data has been written to the database file, and must be called right after the database has been created.

Marks the current transaction as successful. Do not do any more database work between calling this and calling endTransaction. Do as little non-database work as possible in that situation too. If any errors are encountered between this and endTransaction the transaction will still be committed.

Sets the database version.

Returns a string containing a concise, human-readable description of this object. Subclasses are encouraged to override this method and provide an implementation that takes into account the object's type and data. The default implementation is equivalent to the following expression:

          getClass().getName() + '@' + Integer.toHexString(hashCode())
         

See Writing a useful toString method if you intend implementing your own toString method.

Convenience method for updating rows in the database.

Convenience method for updating rows in the database.

Temporarily end the transaction to let other threads run. The transaction is assumed to be successful so far. Do not call setTransactionSuccessful before calling this. When this returns a new transaction will have been created but not marked as successful.

Temporarily end the transaction to let other threads run. The transaction is assumed to be successful so far. Do not call setTransactionSuccessful before calling this. When this returns a new transaction will have been created but not marked as successful. This assumes that there are no nested transactions (beginTransaction has only been called once) and will throw an exception if that is not the case.

Temporarily end the transaction to let other threads run. The transaction is assumed to be successful so far. Do not call setTransactionSuccessful before calling this. When this returns a new transaction will have been created but not marked as successful. This assumes that there are no nested transactions (beginTransaction has only been called once) and will throw an exception if that is not the case.

Invoked when the garbage collector has detected that this instance is no longer reachable. The default implementation does nothing, but this method can be overridden to free resources.

Note that objects that override finalize are significantly more expensive than objects that don't. Finalizers may be run a long time after the object is no longer reachable, depending on memory pressure, so it's a bad idea to rely on them for cleanup. Note also that finalizers are run on a single VM-wide finalizer thread, so doing blocking work in a finalizer is a bad idea. A finalizer is usually only necessary for a class that has a native peer and needs to call a native method to destroy that peer. Even then, it's better to provide an explicit close method (and implement Closeable ), and insist that callers manually dispose of instances. This works well for something like files, but less well for something like a BigInteger where typical calling code would have to deal with lots of temporaries. Unfortunately, code that creates lots of temporaries is the worst kind of code from the point of view of the single finalizer thread.

If you must use finalizers, consider at least providing your own ReferenceQueue and having your own thread process that queue.

Unlike constructors, finalizers are not automatically chained. You are responsible for calling super.finalize() yourself.

Uncaught exceptions thrown by finalizers are ignored and do not terminate the finalizer thread. See Effective Java Item 7, "Avoid finalizers" for more.

Called when the last reference to the object was released by a call to releaseReference() or close() .