Tito, Thanks again for the reply. I am running on Windows 2000 (5.00.2195) SP4, and have an Intel P4 2.40GHz with 1.25gb RAM - there is certainly some contention going on with the file, as I was opening and closing each time.
The problem with having separate pointers is that the threads themselves do not have any idea of the database they will be using, which is wrapped in shared classes. The threads are merely worker threads that do arbitrary jobs. For the time being, I am going to keep the data in memory until it needs committing, and will revisit this at a later stage of the project. Thanks for your help, Steve -----Original Message----- From: Tito Ciuro [mailto:[EMAIL PROTECTED] Sent: Thursday, June 10, 2004 7:58 PM To: Drew, Stephen Cc: '[EMAIL PROTECTED]' Subject: Re: [sqlite] Can't Open Database File Hello Stephen, On Jun 10, 2004, at 18:34, Drew, Stephen wrote: > Tito, > > Thanks for that. I've had a look but it doesn't really help. The two > main questions are: > > 1.) Why do I need a separate sqlite pointer for each thread, if I am > protecting access to it? Honestly, I don't know. I've followed directions as suggested here: http://www.sqlite.org/faq.html#q8 and it's been fine all along. > 2.) Even aside from this, I am using multiple threads to access the > database, each opens it when it needs it, and this is protected by a > critical section, so I have a separate pointer per thread and only one > thread is accessing the DB at a time. Just a question/suggestion: instead of swimming against the current, why not going with the flow? What's wrong with keeping a sqlite structure per thread? It'll simply things quite a bit... > Why do I get "Can't open database" > error? Is this something to do with the filesystem locking? Perhaps > sleeping for a few milliseconds might help? My first question to you: what OS are we talking about? Are you placing the db file on a NFS volume? There are some issues with locking in some OSs. Please elaborate a bit more about the kind of environment you're working on. Regards, -- Tito --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
