| SQLITE3_BLOB_OPEN(3) | Library Functions Manual | SQLITE3_BLOB_OPEN(3) |
sqlite3_blob_open —
open a BLOB for incremental I/O
#include
<sqlite3.h>
int
sqlite3_blob_open(sqlite3*,
const char *zDb, const char
*zTable, const char *zColumn,
sqlite3_int64 iRow, int flags,
sqlite3_blob **ppBlob);
This interfaces opens a handle to the BLOB located in row iRow, column zColumn, table zTable in database zDb; in other words, the same BLOB that would be selected by:
SELECT zColumn FROM zDb.zTable WHERE rowid = iRow;
Parameter zDb is not the filename that contains the database, but rather the symbolic name of the database. For attached databases, this is the name that appears after the AS keyword in the ATTACH statement. For the main database file, the database name is "main". For TEMP tables, the database name is "temp".
If the flags parameter is non-zero, then the BLOB is opened for read and write access. If the flags parameter is zero, the BLOB is opened for read-only access.
On success, SQLITE_OK is returned and the
new BLOB handle is stored in *ppBlob. Otherwise an error code is returned
and, unless the error code is SQLITE_MISUSE, *ppBlob is set to NULL. This
means that, provided the API is not misused, it is always safe to call
sqlite3_blob_close()
on *ppBlob after this function it returns.
This function fails with SQLITE_ERROR if any of the following are true:
Unless it returns SQLITE_MISUSE, this
function sets the database connection error code and message accessible via
sqlite3_errcode()
and
sqlite3_errmsg()
and related functions.
A BLOB referenced by sqlite3_blob_open()
may be read using the
sqlite3_blob_read()
interface and modified by using
sqlite3_blob_write().
The BLOB handle can be moved to a different row of the same table using the
sqlite3_blob_reopen()
interface. However, the column, table, or database of a BLOB handle cannot
be changed after the BLOB handle is opened.
If the row that a BLOB handle points to
is modified by an UPDATE, DELETE, or by ON CONFLICT side-effects then the
BLOB handle is marked as "expired". This is true if any column of
the row is changed, even a column other than the one the BLOB handle is open
on. Calls to
sqlite3_blob_read()
and
sqlite3_blob_write()
for an expired BLOB handle fail with a return code of SQLITE_ABORT. Changes
written into a BLOB prior to the BLOB expiring are not rolled back by the
expiration of the BLOB. Such changes will eventually commit if the
transaction continues to completion.
Use the
sqlite3_blob_bytes()
interface to determine the size of the opened blob. The size of a blob may
not be changed by this interface. Use the UPDATE SQL command to change the
size of a blob.
The
sqlite3_bind_zeroblob()
and
sqlite3_result_zeroblob()
interfaces and the built-in zeroblob SQL function may be used to create a
zero-filled blob to read or write using the incremental-blob interface.
To avoid a resource leak, every open
BLOB handle should eventually be released by a call to
sqlite3_blob_close().
These declarations were extracted from the interface documentation at line 7683.
SQLITE_API int sqlite3_blob_open( sqlite3*, const char *zDb, const char *zTable, const char *zColumn, sqlite3_int64 iRow, int flags, sqlite3_blob **ppBlob );
sqlite3(3), sqlite3_bind_blob(3), sqlite3_blob(3), sqlite3_blob_bytes(3), sqlite3_blob_close(3), sqlite3_blob_read(3), sqlite3_blob_reopen(3), sqlite3_blob_write(3), sqlite3_errcode(3), sqlite3_result_blob(3), SQLITE_OK(3)
| January 24, 2024 | NetBSD 11.0 |