Hi all,

Thanks for your comments...much appreciated......

BTW: if I am using SQLIte as a logger, what PRAGMA statement can I use 
to say FIX the sqlite database size to say "5 MB"?

Also, lets say I have a AUTOINCREMENT INTEGER PRIMARY KEY, what will 
happen when it reaches 5 MB? Will it just keep returning SQLITE_FULL or 
similar? I guess I am looking for a "round robin queue" here?

While I'm on it, if I have an AUTOINCREMENT INTEGER PRIMARY KEY with a 
LOGGER implementation, and the integer reaches it's limit (even though I 
am deleting previous records), will the sqlite database assign "un-used 
primary keys" (previously deleted) to any NEW inserts?

Thanks for the help ;-)

Lynton

On 10/05/2011 12:15, Enrico Thierbach wrote:
> On 10.05.2011, at 12:06, Stephan Beal wrote:
>
>> On Tue, May 10, 2011 at 11:52 AM, Enrico Thierbach<e...@open-lab.org>  wrote:
>>
>>> I don't think sqlite (or any SQL database, for that matter) is a perfect
>>> fit for a logger, because there is a certain amount of write overhead.
>>> Why do you think you would want to do this?
>>>
>> ALL db insertions in a db are, in effect, some form of logging. In embedded
>> apps with no stdout/stderr (e.g. WinCE) using sqlite as a logging
>> destination can be quite useful (and easy to set up).
> Yes and no: logging is an (append-only) write to an already opened file or 
> network socket, and no indexes need to be updated. While inserting a document 
> into a database needs to fiddle with internal database structures, which is 
> less performant than just writing a few bytes to an already handle.
>
> Of course, constraints on an embedded device are different than, say, on a 
> Unix server, and logging to a database is easy to set up, especially if the 
> database is already there :). In other scenarios file system logging 
> generally wins, and not only performance wise, but because there are plenty 
> of tools to work with those; unless, of course, there is a specific need to 
> use a database.
>
> /eno
>
>
>
> _______________________________________________
> 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

Reply via email to