Well, there's the obvious Elephant in the room - SQL. You could just reduce any DB to SQL statements and pass those along at whichever pace/destination/byte-mode you fancy. The target system will have zero trouble turning it into a DB, thanks to the SQLite engine already able to parse SQL.
This can become really efficient later when you only move updated bits - plus, if bandwidth is an issue, SQL text compresses well. Cheers, Ryan On 2015-10-06 03:44 PM, David Barrett wrote: > On Tue, Oct 6, 2015 at 8:36 PM, Simon Slavin <slavins at bigfraud.org> wrote: > >> Or copy an existing /open/ database file to the new server using the >> SQLite Backup API, [requires other connections to stop modifying the >> database for long enough for the copy to be made] >> > Well the backup API works with WAL mode [1] so it can still be modified > while being backed up (though I imagine the WAL file will get huge during > the backup, but that's fine). > > Regardless, all those solutions require me to wait for the entire backup to > complete before sending the file to the remote host -- my goal is to send > it one page at a time (eg, send the pages as the backup API processes them) > so as to avoid the large delay and disk space of the backup itself. > > -david > > [1] http://sqlite.1065341.n5.nabble.com/WAL-mode-and-backup-API-td40107.html > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
