I use the VFS to disable journal file creation and writing. Any possibility to make this part of the sqlite3_open_v2 mode parameter?
That way I could drop my custom VFS. Thanks, Ken "D. Richard Hipp" <[EMAIL PROTECTED]> wrote: The Virtual File System (VFS) layer for SQLite was introduced in version 3.5.0 on 2007-09-04. The VFS interface has made SQLite much easier to port to unusual systems. However, as we have gained experience with the VFS, we have come to realize that the original VFS design has some warts. In particular, not all of the methods in the VFS interface are able to return the errors that some systems want to return. For example, the xAccess() method is used to determine whether or not a file exists. On Unix and win32, the system calls to determine whether or not a file exists cannot fail as long as the call is well-formed (i.e. you give it a valid file descriptor.) The operating system will always be able to give you a straight yes/no answer about whether or not a file exists. And so we made no provisions in the VFS design for the xAccess() method to return an error code. Since then, we have found that some embedded platforms do not work this way and that it is sometimes necessary for xAccess() to fail and say "I don't know". This can happen, for example, when the system is unable to allocate memory for an IPC buffer. To resolve minor problems like this, we are proposing to make incompatible changes to the SQLite VFS layer for version 3.6.0. The changes will be relatively minor (such as allowing xAccess to return an error code in addition to a result) but they are changes all the same and will require VFS implementations targeting 3.5.x to be revised. If you use SQLite exclusively on workstations (unix, O/S2, and/or win32) then you will not notice any changes at all since the VFS layers for these systems are supplied by default. All you have to do is recompile. However, if you have your own custom VFS layer written for an embedded platform, the change to version 3.6.0 may require you to make adjustments to your application code. Note, however, that the adjustments will not be nearly as complex as the migration from 3.4.2 to 3.5.0. Our plan is to release version 3.5.9 prior to starting work on 3.6.0. If the proposed incompatible changes to the VFS layer might cause you hardship, now is the time to make your concerns known. If you have had trouble using the VFS layer and what to suggest API or functionality changes, now would be a good to to do so, prior to us beginning work on version 3.6.0. D. Richard Hipp [EMAIL PROTECTED] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
