Re: [sqlite] sqlite3_open (new Win32 thread)
Dixon Hutchinson wrote: I think this is a different question, unrelated to the previous sqlite_open thread. I'm in a WIN32 environment. I'm using: h = CreateFile(path, GENERIC_READ, FILE_SHARE_READ || FILE_SHARED_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to establish if my DB exists before I open it. If it does exist, I close the handle "h" immediately. I then call sqlite3_open. If the file did not previously exists, I then create my tables. Dioxn, Shouldn't that be: h = CreateFile(, FILE_SHARE_READ | FILE_SHARE_WRITE, ...) With a bitwise OR operator and FILE_SHARE_WRITE not FILE_SHARED_WRITE. You also have a race condition. If another process deletes the file after you close the handle but before sqlite opens it you will end up using an uninitialized database. You should look at using the pragma user_version command to detect if your database has been initialized (search for previous posts). HTH Dennis Cote - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] sqlite3_open (new Win32 thread)
On 12/1/06, Dixon Hutchinson <[EMAIL PROTECTED]> wrote: Just to be safe, I tried specifying FILE_SHARE_WRITE, that did not help. FILE_SHARE_WRITE would allow other "writers" to open the file shared, but should not have any effect on whether this open succeeds. Sharing semantics are bidirectional and affect all opens. In order for two processes to have a particular file open at the same time, they must both agree to share the file for the relevent access rights. If another process has a file open for write access, then you try to open it for read access but do not agree to allow other processes to write to it at the same time, then your open cannot succeed. Otherwise the other process could write to the file when you are not prepared for it, causing you to read inconsistent data. If I ignore the failure and try to open the DB with sqlite3_open, the open succeeds just fine. All I want to do really is test for the existence of the file and whether or not I have permissions to open it with sqlite. sqlite's open calls are in os_win.c. The standard sqlite3WinOpenReadWrite() requests GENERIC_READ and GENERIC_WRITE access, with FILE_SHARE_READ|FILE_SHARE_WRITE sharing. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] sqlite3_open (new Win32 thread)
Trevor, Just to be safe, I tried specifying FILE_SHARE_WRITE, that did not help. FILE_SHARE_WRITE would allow other "writers" to open the file shared, but should not have any effect on whether this open succeeds. If I ignore the failure and try to open the DB with sqlite3_open, the open succeeds just fine. All I want to do really is test for the existence of the file and whether or not I have permissions to open it with sqlite. Trevor Talbot wrote: On 12/1/06, Dixon Hutchinson <[EMAIL PROTECTED]> wrote: I have multiple processes accessing the resulting DB. One of those processes only queries the DB. I call: h = CreateFile(path, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to verify the file exists before declaring an error if it does not exists. The problem is that CreateFile is returning error in this case and GetLastError() tells me that "The process cannot access the file because it is being used by another process." Is there any reason that the second CreateFile above would be incompatible with whatever SQLite uses to open the file? You do not specify FILE_SHARE_WRITE, so if another process has it open with GENERIC_WRITE (or equivalent) permissions, your call will fail. - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] sqlite3_open (new Win32 thread)
On 12/1/06, Dixon Hutchinson <[EMAIL PROTECTED]> wrote: I think this is a different question, unrelated to the previous sqlite_open thread. I'm in a WIN32 environment. I'm using: h = CreateFile(path, GENERIC_READ, FILE_SHARE_READ || FILE_SHARED_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to establish if my DB exists before I open it. If it does exist, I close the handle "h" immediately. I then call sqlite3_open. If the file did not previously exists, I then create my tables. I have multiple processes accessing the resulting DB. One of those processes only queries the DB. I call: h = CreateFile(path, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to verify the file exists before declaring an error if it does not exists. The problem is that CreateFile is returning error in this case and GetLastError() tells me that "The process cannot access the file because it is being used by another process." Is there any reason that the second CreateFile above would be incompatible with whatever SQLite uses to open the file? I'm afraid I don't have an answer to your problem, but is there a reason you can't use the syntax CREATE TABLE IF NOT EXISTS? - To unsubscribe, send email to [EMAIL PROTECTED] - -- Cory Nelson http://www.int64.org - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] sqlite3_open (new Win32 thread)
On 12/1/06, Dixon Hutchinson <[EMAIL PROTECTED]> wrote: I have multiple processes accessing the resulting DB. One of those processes only queries the DB. I call: h = CreateFile(path, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to verify the file exists before declaring an error if it does not exists. The problem is that CreateFile is returning error in this case and GetLastError() tells me that "The process cannot access the file because it is being used by another process." Is there any reason that the second CreateFile above would be incompatible with whatever SQLite uses to open the file? You do not specify FILE_SHARE_WRITE, so if another process has it open with GENERIC_WRITE (or equivalent) permissions, your call will fail. - To unsubscribe, send email to [EMAIL PROTECTED] -
