You've got the source code. Modify sqlite3journalopen to put your journal in %TEMP% or or maybe getcwd(). I couldn't quite figure out where the journal filename is set -- there's no db-journal in the code so the name setting appears magjic to me. Since you've got complete control over the source you can do what you want (ain't that nice?) Also, try PRAGAM locking_mode=EXCLUSIVE; That might save you some time too. Michael D. Black Senior Scientist Northrop Grumman Mission Systems
________________________________ From: sqlite-users-boun...@sqlite.org on behalf of Werner Smit Sent: Wed 7/14/2010 6:33 AM To: General Discussion of SQLite Database Subject: EXTERNAL:Re: [sqlite] Sqlite Insert Speed Optimization -----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Paul Corke Sent: 14 July 2010 01:03 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Sqlite Insert Speed Optimization On 14 July 2010 11:56, Werner Smit wrote: > 3. I'm saving to a network drive. Is this a one-off data import into a new clean sqlite db? If so have you considered writing to a db file on a local drive and then copying the whole file to the network drive afterwards? Paul. I have considered that! I do allow the users to do a clean build or an update. Clean build is usually once a week - I could build that on local drive BUT the problem is if the copy fail and leave them with incomplete file I'm in trouble. To manage this and make sure all is well is not an easy task. I did check and the sqlite speed on local drive seem to be much faster. Would it be possible to tell sqlite to save journal file to local drive and merge with server file on transaction completion? Another option - with much more work would be to create a db on local drive, fill it with X records and start a seperate thread to merge this with network drive while my program is busy fetching the next X record batch. But if at all possible I'd like to not make too many changes to the current program. I like the kiss scenario. "keep it short and simple" DISCLAIMER: Everything in this email and its attachments relating to the official business of Face Technologies is proprietary to Face Technologies. It is confidential, legally privileged and protected by law. The person addressed in the email is the sole authorised recipient. Any unauthorized dissemination or copying of this e-mail (or any attachment to this e-mail) or the wrongful disclosure of the information herein contained is prohibited. _______________________________________________ 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
