Darren Duncan wrote:
> That doesn't sound right. sqlite3_open() *should* return an error when you try opening a 2.x database, citing that the file is not a SQLite (v3) database file.
>
> Incidentally, I would expect that the simple solution is to do this: When given a file name to open, first try to open it with the v3 binary; if that returns an error citing 'not a SQLite database', then try opening it with the v2 binary; if neither fails to work, then the file isn't v3 or v2. Otherwise, based on which open() worked, your program logic now knows which binary/functions to use for further interactions with the file.
That's a good strategy, but with the current build you will only get the error after performing your first SQL operation on the db, not immediately after opening it.
Just to be absolutely sure I just retested with the official
sqlite3
binary posted a couple of minutes ago (3.03), using a database in the old format.
Some operations do not trigger an error, probably because they only setup internal states and do not actually touch the data. I found for example that:
pragma show_datatypes = ON;
does not trigger any errors, and this is what I had in my code immediately after opening. However,
pragma synchronous = ON;
does trigger the error, as well as any attempt to get data from the db (or the schema). So the strategy I have now is:
a) use sqlite3_open
b) trigger "pragma synchronous = ON;"
c) collect an error message, if it is 26 then
d) use sqlite_open (old format)
e) trigger "pragma synchronous = ON;" again
f) watch for any error messages here.
g) if it opens without errors, maybe offer the user the option to convert to sqlite3 format.
This will probably be a common scenario for several programs, so maybe detecting a database in the old format and returning the appropriate error directly in sqlite3_open could save some time.
Regards, Mauricio
