[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sqlite-users
Subject:    Re: [sqlite] smartest way to exchange a sqlite3 database with another empty
From:       Domingo Alvarez Duarte <mingodad () gmail ! com>
Date:       2016-10-03 13:09:17
Message-ID: 70e007b2-029a-0156-6ba7-2599e8363a80 () gmail ! com
[Download RAW message or body]

Hello Richard !

Ok I missed this point, but still while fighting to use sqlite3 with big 
databases I was thinking on some custom changes to allow sqlite relax 
some restrictions:
1- Create a new sqlite reserved table for register attached databases, 
this way every time a program try to open an sqlite3 database it will 
look if this table exists and will automatically attach then, also will 
allow views and triggers between attached databases.
2- For operations like "vacuum" and to force processes to reopen the 
database another sqlite reserved table could be created like 
"sqlite_open_instead" if that table exists it indicates anyone trying to 
open that database to open the one indicated there instead, this would 
work on any operating system (maybe not too elegant but it should work, 
or anything else using a similar mechanism).

Cheers !

On 03/10/16 09:53, Richard Hipp wrote:
> On 10/3/16, Domingo Alvarez Duarte <mingodad@gmail.com> wrote:
>> Hello !
>>
>> Thinking about this and the problem I'm experiencing with big databases
>> with sqlite3 "vacuum" probably could be a good idea to use a flag in the
>> sqlite3 header to inform other processes to reopen the database.
>>
> That might work on unix.  But on Windows, the operating system
> prohibits files from being renamed while the file is open.
>

_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[prev in list] [next in list] [prev in thread] [next in thread]