At 19:12 20/05/2008, you wrote: >Actually my reason for writing into a seperate database is more... >well crude. I tar several databases together then encrypt using >openSSL. Then an FTP like program transmits the data a central server. > I must suspend writing into the database for the duration of the tar >operation since tar does not abide by sqlites file locking rules.
Perhaps i've missed something or don't understand it well. Your databases is all on the same file or do you have 2 separate sqlite sessions to 2 different databases files? In the first scenario you must be very fast and in the second you can switch from one database to the other, unbind (close) the sqlite, do ftp or what ever you want and delete database file. You attach x+1 to x. Why do you need it? If you delete old records on x after the ftp you can trash x, work with x+1 and recreate a void x. I think you only need 2 databases and while you add data to A, you copy and delete B. Then switch A and B. Perhaps you need 3 databases, and separate the download and . On the other side you can attach the databases and reconstruct one big database. If you need compression you can check any lzp, lzo or lzrh algorithms, they are very fast, and compress the files "on the fly". This compression algorithms works well with text data and bad with binary data. Take care because sqlite does already compress data in the databases files. HTH ---------------------------------------------------------------------- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
