Ken - You could write your own VFS that overrides the xOpen method so that it doesn't create a journal file. Quoting from the documentation:
"The file I/O implementation can use the object type flags to change the way it deals with files. For example, an application that does not care about crash recovery or rollback, might make the open of a journal file a no-op. Writes to this journal are also a no-op. Any attempt to read the journal returns SQLITE_IOERR." The object type flags referred to in the above paragraph are included in the 'flags' parameter passed to xOpen. See http://www.sqlite.org/34to35.html for more details. - Richard Ken wrote: > Maybe this could be added as a "Feature request" to open_v2 ? > > Add, > > #define SQLITE_OPEN_OMIT_JOURNAL 0x00008000 > > Test this flag and set the omit_journal parameter to Btree factory... To > cause sqlite to omit journal creation. Obviously this has serious impact to a > databases recoverability. But when the Durability component of ACID is not > needed it should provide a nice performance boost! > > In my particular case, I have many small db files that have data. These are > "batched" into a db file. If the process fails the in progress batch will > simply be overwritten and re-created. Hence it is an all or none approach and > does not need any recoverability. > > Thanks, > Ken > > > > > _______________________________________________ > 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
