On Apr 18, 2008, at 1:25 :36PM, Dennis Cote wrote: > James Gregurich wrote: >> >> suppose I create a temporary db file on disk. Each task ( a thread) >> opens a connection to the temp file and attaches an in-memory db to >> it. > > You will have to open the memory database and attach the db file since > SQLite can't attach to a memory database.
is this information wrong? http://www.blitzbasic.com/Community/posts.php?topic=60981 > > > Why have you proposed to use a temporary database file? Can this > data be > destroyed between executions? yes. the nature of the application is such that the data is loaded from a proprietary file format, processed, and presented to the user. There is no need to store the data back on disk. I'm interested in a flexible, convenient, in-memory datastore. I thought it was going to work but was stopped dead in my tracks when I realized I couldn't open multiple connections on an in-memory db. > > The way I have suggested, the readers only open the database file. > They > can read as long as no update is in progress. The updates will be > batched into the independent memory database. During an update the > database file will be locked, so readers will have to wait. great. that will get me concurrency at the expense of unnecessary disk I/O. I suppose I will have to decide if using sqlite is worth the price. I may just fall back to defining a table as a std::vector<> of std::map<> entries and skip the whole idea of using an embedded db engine. I'll have to think about all of this. thanks, James _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users