Which method returns an error for a table that is missing it's backing store determines what can be done.
xBestIndex: prevents SQLite from preparing a statement that requires reading the table (even no rows will be retrieved) xOpen: prevents SQLite from opening a cursor on the table (i.e. the first call to sqlite3_step fails) xFilter: prevents SQLite from reading the first row from the table (i.e. the first attempt to actually get a specific row from this table fails; this may be well into the query) The proper choice depends on what the missing backing store means to you application wise. -----Urspr?ngliche Nachricht----- Von: Samuel Debionne [mailto:samuel.debionne at ujf-grenoble.fr] Gesendet: Mittwoch, 10. Juni 2015 10:28 An: General Discussion of SQLite Database Betreff: Re: [sqlite] DROP statement on Virtual Tables Thank you for your thoroughful answers ! Following your advices, I have split XCreate and xConnect implementations, the first enforces the existence of the resource while the later returns SQLITE_OK even if the resource is missing. > The proper place to implement handling a missing backing storage file > is xOpen (for SELECT) and xUpdate (for INSERT/UPDATE/DELETE). You > choose to either return an error there, or silently provide no rows on > SELECT and ignore INSERTs. Well, it seems that xBestIndex is called first (for SELECT). If I return SQLITE_IOERR from xBestIndex, SQLite crashes. xConnect requires that ppVTab is allocated, initialized and a dummy vtab schema should be declared : sqlite3_declare_vtab(db, "CREATE TABLE missing_vt(uid INTEGER)"); Something similar should probably be done for xBestIndex and the sqlite3_index_info structure. But this is really confusing the implementation... > 3) pragma writeable_schema; delete from sqlite3_master where > name='mycsv'; This may be the best option actually ! I think I will go for it and add a ".drop VTABLE" command to my shell... It would be great to have better support for this scenario: if the statement is a DROP TABLE on a virtual table, allows xConnect to fail and remove the table from sqlite3_master. _______________________________________________ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___________________________________________ Gunter Hick Software Engineer Scientific Games International GmbH FN 157284 a, HG Wien Klitschgasse 2-4, A-1130 Vienna, Austria Tel: +43 1 80100 0 E-Mail: hick at scigames.at This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation.
