Hi,
thanks but we will write our own SQLite class.
Our class provides something like that:
FSqlite sql;
sql.sqliteConnect("myDatabase");
sql.query("select * from my table");
while(sql.next())
cout << sql.value("myRow");
I think this is really easy...
If there will be a new SQLite version we
> Will the [SQLite 3] API change much? What do you think -> do we need to
rewrite much code
> if we use the function with the callback method?
>From what I can see, the SQLite 3 proposal does not commit to keeping the
sqlite_exec() function.
>>If you want to move to version 3, the API will
>>be
Hi Richard,
> Version 2 (with the existing API) will continue to be
> supported with bug fixes (as needed) for the foreseeable
> future. If you want to move to version 3, the API will
> be very similar, but there will be a few differences.
> You will not need to change much code, I don't think,
Christian Kienle wrote:
SQLite version 3 is currently under development. sqlite3_open() will
have a flexible mechanism to specify options. It will not have the
second parameter currently found on sqlite_open().
Will the API change much? What do you think -> do we need to rewrite much code
if we
Hi,
at first thank you for the information you gave us.
> There are no plans to ever do anything with the second argument to
> sqlite_open().
Ah okay...
> SQLite version 3 is currently under development. sqlite3_open() will
> have a flexible mechanism to specify options. It will not have the
>
Christian Kienle wrote:
"Use the sqlite_open function to open an existing SQLite database or to create
a new SQLite database. The first argument is the database name. The second
argument is intended to signal whether the database is going to be used for
reading and writing or just for reading. B
6 matches
Mail list logo
