Page History
- 2007-Apr-26 10:41 anonymous
- 2007-Apr-25 08:38 anonymous
- 2007-Apr-16 21:55 anonymous
- 2007-Apr-16 06:43 anonymous
- 2006-Oct-31 15:41 anonymous
- 2006-Sep-09 04:51 anonymous
- 2006-Jun-28 14:29 anonymous
- 2006-Jun-28 05:36 anonymous
- 2006-Jun-28 05:25 anonymous
- 2006-Jun-28 05:22 anonymous
- 2006-Mar-14 00:02 anonymous
- 2006-Mar-14 00:02 anonymous
- 2006-Feb-22 15:07 anonymous
- 2006-Feb-20 15:07 anonymous
- 2006-Jan-08 00:40 anonymous
- 2005-Nov-02 13:02 anonymous
- 2005-Jul-03 18:31 anonymous
- 2005-Mar-26 07:47 anonymous
- 2005-Mar-25 15:03 anonymous
- 2004-Sep-12 10:21 anonymous
- 2004-Aug-08 00:47 anonymous
- 2004-Apr-14 04:51 anonymous
- 2004-Apr-14 04:50 anonymous
- 2003-Oct-22 01:18 anonymous
- 2003-Oct-21 19:44 anonymous
- 2003-Oct-21 19:23 anonymous
- 2003-Sep-29 07:03 anonymous
- 2003-Jul-06 21:57 drh
- 2003-May-10 03:20 anonymous
- 2003-Apr-16 14:21 drh
- 2003-Apr-16 13:50 anonymous
- 2003-Feb-05 02:03 anonymous
- 2003-Feb-04 23:27 anonymous
- 2003-Feb-04 23:23 anonymous
2003-04-15: The in-memory database is now in the CVS tree, though it is still mostly untested.
2003-05-09: In-memory databases are now a feature of the standard SQLite library. To open an in-memory database, use filename ":memory:".
While connections to on-disk databases should not be carried across a Unix fork(), is there any reason not to do it with an in-memory database? (2003-10-21 by drh:) Not that I know of.
DK: Of course, when you do the fork() you are creating a new copy of the in-memory db for the child process. So subsequent edits to the db in the child won't show up in the parents copy, and vice-versa.