If you're trying to copy a file while connections still have it open
then you should use SQLite API calls to do it. The obvious ones are
in the SQLite Online Backup API, which is the set of calls underlying
the '.backup' command you mentioned. You can find documentation for
`ATTACH` and iterating over all tables with `INSERT INTO SELECT` is how `VACUUM
INTO` is implemented (see src/vacuum.c).
A less complicated way to back up the database might be to run `BEGIN` followed
by `PRAGMA user_version` to acquire a read lock, after which you can safely
copy the database
On 18 Mar 2019, at 3:21pm, Jonathan Moules wrote:
> At this point I'm starting to think that the best option is to create a new
> database with the requisite structure and copy the data across via an ATTACH
> (there are only two tables and one will almost always be empty at this point).
If the php sqlite bindings are incomplete and don't support the backup
functions, write a small program in C that uses them to copy a database,
and execute that from the php code?
On Mon, Mar 18, 2019, 8:24 AM Jonathan Moules
> Hi Simon,
> Thanks for your thoughts. Sorry, I should have
Thanks for your thoughts. Sorry, I should have been clearer: I have no
way of knowing if there are other open connections to the file - there
may be as it's a web-application. So I'll assume there are connections.
At this point I'm starting to think that the best option is to
On 18 Mar 2019, at 1:10pm, Jonathan Moules wrote:
> I was wondering if there was a good way of backing up an SQLite database if
> you do *not* have access to the SQLite command line tool (which I know has
> .backup - https://stackoverflow.com/a/25684912). [snip]
> I've considered simply
I was wondering if there was a good way of backing up an SQLite database
if you do *not* have access to the SQLite command line tool (which I
know has .backup - https://stackoverflow.com/a/25684912).
The new VACUUM INTO (https://www.sqlite.org/lang_vacuum.html#vacuuminto)
is not an
Mail list logo