1.Dd December 18, 2016 2.Dt SQLITE3_STMT_READONLY 3 3.Os 4.Sh NAME 5.Nm sqlite3_stmt_readonly 6.Nd Determine If An SQL Statement Writes The Database 7.Sh SYNOPSIS 8.Ft int SQLITE_STDCALL 9.Fo sqlite3_stmt_readonly 10.Fa "sqlite3_stmt *pStmt" 11.Fc 12.Sh DESCRIPTION 13The sqlite3_stmt_readonly(X) interface returns true (non-zero) if and 14only if the prepared statement X makes no direct 15changes to the content of the database file. 16.Pp 17Note that application-defined SQL functions 18or virtual tables might change the database indirectly 19as a side effect. 20For example, if an application defines a function "eval()" that calls 21sqlite3_exec(), then the following SQL statement would 22change the database file through side-effects: 23.Bd -ragged 24.Bd -literal 25SELECT eval('DELETE FROM t1') FROM t2; 26.Ed 27.Pp 28.Ed 29.Pp 30But because the SELECT statement does not change the database 31file directly, sqlite3_stmt_readonly() would still return true. 32.Pp 33Transaction control statements such as BEGIN, COMMIT, ROLLBACK, 34SAVEPOINT, and RELEASE cause sqlite3_stmt_readonly() 35to return true, since the statements themselves do not actually modify 36the database but rather they control the timing of when other statements 37modify the database. 38The ATTACH and DETACH statements also cause sqlite3_stmt_readonly() 39to return true since, while those statements change the configuration 40of a database connection, they do not make changes to the content of 41the database files on disk. 42.Sh SEE ALSO 43.Xr sqlite3_create_function 3 , 44.Xr sqlite3_stmt 3 , 45.Xr sqlite3_exec 3 46