Roger Binns wrote:
Alternately, you may want to consider the simpler sqlite3_exec api
Roger,
The sqlite3_exec interface may seem simpler than the sqlite_prepare et
al API at first glance, but it really isn't for queries. Yes you make
fewer calls to sqlite functions, but you have to define a callback
function to handles the results. Moreover, the results are all presented
to your application as strings, so you have to convert any non string
values to the required type, but no type information is available to the
callback function.
The following code shows how to read the oid values into a vector using
the sqlite3_prepare family of calls, but skips the error checking for
clarity.
vector oids;
sqlite3_stmt *s;
int rc = sqlite3_prepare(db, "select OID from tablename", -1, , NULL);
while ((rc = sqlite3_step(s)) == SQLITE_ROW) {
int oid = sqlite3_column_int(s, 0);
oids.push_back(oid);
}
rc = sqlite3_finalize(s)
It really isn't any more complicated than the sqlite3_exec version, and
many would find it easier to understand.
vector oids;
static int callback(void *user_data, int argc, char **argv, char
**azColName)
{
int oid = atoi(argv[0]);
((vector*)user_data)->push_back(oid);
}
sqlite3_exec(db, "select OID from tablename", callback, , NULL);
The sqlite3_prepare interface avoids unnecessary string conversions, and
has more potential for optimization by reusing previously prepared
queries. It also allows the user to modify some parts of a prepared
query using bound variables rather than recompiling the entire SQL query
from scratch. I thinks its usually worth the time it takes to learn how
to use it.
Dennis Cote
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
