Removing the persistant instance of a virtual table is the most common way of tripping up a virtual table implementation.
Just because xCreate and xConnect have identical interfaces does not mean that they are identical (although, with care, you can use the same routine to perform both tasks). Even if the documentation is a little misleading in this matter. xCreate is called in response to the SQL "CREATE VIRTUAL TABLE" command and is expected to create a (persistant) instance of the table. If it fails, the transaction fails and the table is not registered in sqlite3_master. xConnect is called whenever SQLite decides it needs to do something with the existing virtual table. There must have been a successful xCreate call (in another session, another thread or another process) before. xConnect is not allowed to fail, even if whatever storage implements the persistant data is no longer present. It should just take note of that fact and let the other routines react appropriately. xDestroy is called in response to the SQL "DROP TABLE" command and is passed the structure allocated by xConnect (which is why this must NEVER fail). It is expected to remove whatever persistant instance xCreate created. xDisconnect is just expected to free any resources allocated by xConnect. If your CSV File goes missing before your application is finished reading, too bad, just make sure that DROP TABLE can be executed so that SQlite can remove the bookkeeping entries from the SQLite db file. If your CSV File may be needed later, xDestroy should not delete it... -----Urspr?ngliche Nachricht----- Von: Samuel Debionne [mailto:samuel.debionne at ujf-grenoble.fr] Gesendet: Dienstag, 09. Juni 2015 11:47 An: sqlite-users at mailinglists.sqlite.org Betreff: [sqlite] DROP statement on Virtual Tables Hello, AFAIU, when executing a drop statement on a virtual table, the XConnect callback is executed first, then XDestroy. Now I have the following scenario where my virtual table is related to a file (say a CSV file): 1. Create the virtual table 2. Delete the CSV file from disk 3. Try to drop the table (fails) When creating the vtable, xCreate / xConnect should fail (returns SQLITE_ERROR) if the underlying file does not exists. But when dropping the vtable, this very same xConnect should continue to let the user drop a table on a deleted file. Is there a way to know the "context", e.g. the SQL command, that has triggered a call to xConnect ? Or is there a better way to tackle this issue ? Thank you, Samuel _______________________________________________ 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.
