On 1 Mar 2013, at 12:24pm, Dave McKee <[email protected]> wrote:
> I'm considering working with a dump of the SQL database, and I'm anxious to > make sure that nothing gets lost in the transformation. I assume you're talking about the '.dump' function of the shell tool, which creates a set of commands which could be used to reproduce the database. > I'm aware that the database will effectively be vacuumed and that rowids > won't be preserved. I'm happy about the first and can live with the second. If you want to make sure that rowid values are preserved, define your own INTEGER PRIMARY KEY column in each table. SQLite will (effectively) make this an alias to the rowid column and since SQLite knows you might be referring to those values by name, it will never change them in a VACUUM and the .dump command will list them. > What else isn't losslessly maintained in a dump -> load cycle? > > Is there anything else that would negatively affect database performance, > the results of SQL queries or the databases configuration (e.g. WAL mode)? WAL mode isn't a problem. Your entire journals will be lost since you will be creating a new database. I believe you're right that the .dump command does not dump any PRAGMA settings stored in the database (perhaps it should) so PRAGMA settings may be lost. The thing that does come to mind is minor: any results of ANALYZE will be lost. It's easy to regain them once you're read your data into a new database though, and this will update them at the same time. Simon. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
