On Aug 1, 2008, at 3:14 PM, Arun Bhalla wrote: > Hi there, > > We are performing backups of the SQLite DB file by opening an > IMMEDIATE > transaction and then copying the file. (cf. > <http://www.mail-archive.com/sqlite-users@sqlite.org/msg19265.html>, > <http://www.mail-archive.com/sqlite-users@sqlite.org/msg19311.html>) > > On Windows we use CopyFileA (within the same process that opened the > DB > transaction) to perform the copy. We've noticed that copies fail on > Windows for databases larger than 1 GB in size. We suspect this is > due > to SQLite locking bytes around the 1GB offset whenever a transaction > is > opened on Windows. This may be due to the fact that the locking file > handle gets exclusive access; other file handles opened by the same > process also cannot access the same locked region. (cf. > <http://msdn.microsoft.com/en-us/library/aa365202(VS.85).aspx>) > > What we're thinking of doing is pushing the PENDING_BYTE from the > first > byte past the 1GB boundary to somewhere deep in the 64-bit range (such > as perhaps the 1TB boundary). We would have to update many lock and > unlock calls in os_win.c to do so, mainly adding a high-order 32-bit > number to the lock offset. Is anyone aware of any issues with doing > so, > either with SQLite or Windows? Would we have to change anything > else in > SQLite other than in os_win.c? We don't use anything older than > Windows > 2000, so older systems shouldn't be a concern for us.
You can change it and it will probably work. But the resulting SQLite library will not be compatible with the standard SQLite library. If you application has the database locked, the sqlite3.exe CLI that you download from the SQLite website will not realize this (because the locks are in the wrong place) and trouble will result. D. Richard Hipp [EMAIL PROTECTED] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
