On Tue, 9 Jun 2015 15:13:47 +0000 Hick Gunter <hick at scigames.at> wrote:
> 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. I don't see how xConnect can not be allowed to fail. The documentation says it may return SQLITE_ERROR, and it must allocate the sqlite3_vtab structure, which can fail. If a required resource is not available, ISTM returning an error is well advised, lest a call to later function fail more mysteriously. That said, the putative CSV file cannot be deleted between xCreate and xConnect if the vtable holds a descriptor to the file. In Linux, the file may be unlinked, but the inode is preserved while any open descriptor remains. In Windows, the user is prevented from deleting an open file. Of course the file may go away anyway. It might be on a USB drive and the user may pull it. In general, the hardware may fail. That's another reason xConnect may return an error. --jkl
