1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
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
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
.Dd January 24, 2024
.Dt SQLITE3_STEP 3
.Os
.Sh NAME
.Nm sqlite3_step
.Nd evaluate an SQL statement
.Sh SYNOPSIS
.In sqlite3.h
.Ft int
.Fo sqlite3_step
.Fa "sqlite3_stmt*"
.Fc
.Sh DESCRIPTION
After a prepared statement has been prepared using
any of
.Fn sqlite3_prepare_v2 ,
.Fn sqlite3_prepare_v3 ,
.Fn sqlite3_prepare16_v2 ,
or
.Fn sqlite3_prepare16_v3
or one of the legacy interfaces
.Fn sqlite3_prepare
or
.Fn sqlite3_prepare16 ,
this function must be called one or more times to evaluate the statement.
.Pp
The details of the behavior of the sqlite3_step() interface depend
on whether the statement was prepared using the newer "vX" interfaces
.Fn sqlite3_prepare_v3 ,
.Fn sqlite3_prepare_v2 ,
.Fn sqlite3_prepare16_v3 ,
.Fn sqlite3_prepare16_v2
or the older legacy interfaces
.Fn sqlite3_prepare
and
.Fn sqlite3_prepare16 .
The use of the new "vX" interface is recommended for new applications
but the legacy interface will continue to be supported.
.Pp
In the legacy interface, the return value will be either SQLITE_BUSY,
SQLITE_DONE, SQLITE_ROW, SQLITE_ERROR,
or SQLITE_MISUSE.
With the "v2" interface, any of the other result codes
or extended result codes might be returned as
well.
.Pp
SQLITE_BUSY means that the database engine was unable to
acquire the database locks it needs to do its job.
If the statement is a COMMIT or occurs outside of an explicit
transaction, then you can retry the statement.
If the statement is not a COMMIT and occurs within an explicit
transaction then you should rollback the transaction before continuing.
.Pp
SQLITE_DONE means that the statement has finished executing
successfully.
sqlite3_step() should not be called again on this virtual machine without
first calling
.Fn sqlite3_reset
to reset the virtual machine back to its initial state.
.Pp
If the SQL statement being executed returns any data, then SQLITE_ROW
is returned each time a new row of data is ready for processing by
the caller.
The values may be accessed using the column access functions.
sqlite3_step() is called again to retrieve the next row of data.
.Pp
SQLITE_ERROR means that a run-time error (such as a constraint
violation) has occurred.
sqlite3_step() should not be called again on the VM.
More information may be found by calling
.Fn sqlite3_errmsg .
With the legacy interface, a more specific error code (for example,
SQLITE_INTERRUPT, SQLITE_SCHEMA, SQLITE_CORRUPT,
and so forth) can be obtained by calling
.Fn sqlite3_reset
on the prepared statement.
In the "v2" interface, the more specific error code is returned directly
by sqlite3_step().
.Pp
SQLITE_MISUSE means that the this routine was called inappropriately.
Perhaps it was called on a prepared statement that
has already been finalized or on one that had previously returned
SQLITE_ERROR or SQLITE_DONE.
Or it could be the case that the same database connection is being
used by two or more threads at the same moment in time.
.Pp
For all versions of SQLite up to and including 3.6.23.1, a call to
.Fn sqlite3_reset
was required after sqlite3_step() returned anything other than SQLITE_ROW
before any subsequent invocation of sqlite3_step().
Failure to reset the prepared statement using
.Fn sqlite3_reset
would result in an SQLITE_MISUSE return from sqlite3_step().
But after version 3.6.23.1 (dateof:3.6.23.1,
sqlite3_step() began calling
.Fn sqlite3_reset
automatically in this circumstance rather than returning SQLITE_MISUSE.
This is not considered a compatibility break because any application
that ever receives an SQLITE_MISUSE error is broken by definition.
The SQLITE_OMIT_AUTORESET compile-time option
can be used to restore the legacy behavior.
.Pp
\fBGoofy Interface Alert:\fP In the legacy interface, the sqlite3_step()
API always returns a generic error code, SQLITE_ERROR,
following any error other than SQLITE_BUSY and SQLITE_MISUSE.
You must call
.Fn sqlite3_reset
or
.Fn sqlite3_finalize
in order to find one of the specific error codes that better
describes the error.
We admit that this is a goofy design.
The problem has been fixed with the "v2" interface.
If you prepare all of your SQL statements using
.Fn sqlite3_prepare_v3
or
.Fn sqlite3_prepare_v2
or
.Fn sqlite3_prepare16_v2
or
.Fn sqlite3_prepare16_v3
instead of the legacy
.Fn sqlite3_prepare
and
.Fn sqlite3_prepare16
interfaces, then the more specific error codes are returned
directly by sqlite3_step().
The use of the "vX" interfaces is recommended.
.Sh IMPLEMENTATION NOTES
These declarations were extracted from the
interface documentation at line 4904.
.Bd -literal
SQLITE_API int sqlite3_step(sqlite3_stmt*);
.Ed
.Sh SEE ALSO
.Xr sqlite3_column_blob 3 ,
.Xr sqlite3_errcode 3 ,
.Xr sqlite3_finalize 3 ,
.Xr sqlite3_prepare 3 ,
.Xr sqlite3_reset 3 ,
.Xr sqlite3_stmt 3 ,
.Xr SQLITE_OK 3
|
