I've done an app like that before with a different db foundation. Basically 2 different databases, same structure. The logging app hits an ini file before each write, if the current db is different than the name in the ini file then close the current db, open the new db and write the row to the new db, otherwise write the row to the current db.
I had background app that ran as a service and would switch the fb name in the ini file when one hour had passed or the db was full. It worked great . Woody from his pda -----Original Message----- From: A.J.Millan <[EMAIL PROTECTED]> Sent: Wednesday, May 21, 2008 2:29 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] design question / discussion Rich Rattanni wrote:>Hi I have a general design question. I have the following senario... >In an embedded system running linux 2.6.2x I have a sqlite database >constantly being updated with data acquired by the system. I cant >lose data (hence why I am using sqlite in the first place). However >periodically I have download the data contain within the database to a >central server. The system cannot stall during the download and must >continue to record data. Also, after the download I need to shrink >the database size, simply because if the database is allowed to grow >to its max size (~50MB) then every download thereafter would be 50MB, >which is unacceptable. After thinking in your's problem, according to yours first exposition, it seems that you are using the SQLite dbase as a mere tampon or temporarybuffer to the acquired data. In that condition, with no further process of those data in the embedded system, perhaps you can consider simply write a flat file appending to it the incoming data (may be alternating between two or more files) and then compress and send the data to the host where they can be further processed or appended to a dbase. >From the security point of view, the data in the embedded device are not necesarily safer in a SQLite dbase that in a flat file. Perhaps that layer(SQLite) are not necessary at all in the embedded device. Just thinking out loud :-) Adolfo. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users