Actually, I have just realized that I indeed cannot use BEGIN IMMEDIATE to
do the locking because it has to be locked from the process that has no
SQLite in it...
And you already delievered the exact answer of how to do it!
Thanks a lot!
Ran
On 6/22/06, Christian Smith <[EMAIL PROTECTED]> wrote:
Igor Tandetnik uttered:
> Christian Smith
> <[EMAIL PROTECTED]> wrote:
>> Igor Tandetnik uttered:
>>> You want to enable sharing. Pass FILE_SHARE_READ | FILE_SHARE_WRITE
>>> as the third parameter.
>>
>>
>> Surely not FILE_SHARE_WRITE! You don't want other processes writing
>> the database while you're copying it.
>
> The file is already opened by another process for read/write, you must
> specify FILE_SHARE_WRITE otherwise you won't be able to open it. You
have to
> impose a locking mechanism separate from that provided by the OS. Hence
BEGIN
> IMMEDIATE command which guarantees that no writes will occur via SQLite.
But the OP didn't want to use SQLite in the copying program (for whatever
reason). Without SQLite to arbitrate locking, using
FILE_SHARE_WRITE won't help any as the file can still be updated
regardless while we're copying. If the file is already open with SQLite,
then we're stuck with it I suppose.
The OP's best bet, then, is to lock the file an a way compatible with
SQLite. The easiest way to do this is to use the Win95 compatible LockFile
similar to the function getReadLock in the os_win.c source. Use the
following code to read lock the file in a SQLite compatible way:
#define PENDING_BYTE 0x40000000 /* First byte past the 1GB boundary */
#define SHARED_FIRST (PENDING_BYTE+2)
#define SHARED_SIZE 510
static int getReadLock( HANDLE fhandle )
{
int lk = random();
int sharedLockByte = (lk & 0x7fffffff)%(SHARED_SIZE - 1);
return res = LockFile( fhandle, SHARED_FIRST+sharedLockByte, 0, 1, 0);
}
Note, this function will fail (return 0) if the file is already locked for
writing, as the entire region from SHARED_FIRST to
SHARED_FIRST+SHARED_SIZE is locked. The function will also fail on NT if
the SQLite library already has a read lock on the file. If you want a more
complete function that is more capable on NT, look at the getReadLock() in
os_win.c.
If closing the handle does not clear the lock, you'll need to record the
sharedLockByte value and unlock the file first. MSDN is unclear whether
this is the case (no surprises there!)
>
> Igor Tandetnik
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
