[sqlite] Compiling sqlite using chars unsigned by default
Great! Thanks. On May 8, 2009, at 3:34 PM, Axel Mammes wrote: > Hi, I am using the ARM RVDS 2.0.1 compiler to try to get SQLite on a > VeriFone Vx570 point of sale terminal running VerixV operating > system. I am > still working on getting it to work, but before I continue I need to > know if > the fact that chars are unsigned by default will break sqlite build. It should work fine. D. Richard Hipp d...@hwaci.com ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Compiling sqlite using chars unsigned by default
Hi, I am using the ARM RVDS 2.0.1 compiler to try to get SQLite on a VeriFone Vx570 point of sale terminal running VerixV operating system. I am still working on getting it to work, but before I continue I need to know if the fact that chars are unsigned by default will break sqlite build. Thanks Axel ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Porting SQL to run on a proprietary operating system
I gave up on this port. Far more complicated than what I initially thought. Guess I'll have to implement stupid flat files manually. :(( On 12/30/05, Jay Sprenkle <[EMAIL PROTECTED]> wrote: > Yes, most people load the data to persistant memory when shutting > down, or periodically > to save a snapshot, and load it when booting up. It's fast but if your > hardware > can't detect a power failure and write the data with what power > remains in the power supply > capacitors you risk losing some data in case of power failure between > snapshots. > > On 12/30/05, Axel Mammes <[EMAIL PROTECTED]> wrote: > > If I use memory database, the content will be zeroed when I reboot the > > equipment. Only memory that is allocated for the filesystem is > > persistant between power cycles. > > >
Re: [sqlite] proposal for improving concurrency in SQLite
How about using a hard-link to store the log file somewhere else? That should work transparently... On 1/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> wrote: > > On Mon, Jan 09, 2006 at 09:08:10PM -0800, Dan Kennedy wrote: > > > > > > The short version: > > > > > > The first write operation writes the parts of the database that > > > are about to be overwritten to the journal file. If something > > > goes wrong during the second write, the journal file will be > > > used to restore the database to it's previous state. The second > > > write is the one that actually modifies the database file. > > > > Yes, but the second write (to the data files) isn't time critical. > > Because it doesn't (or at least shouldn't) be getting fsync'd very > > often, it can also be re-ordered by the OS (and possibly the drive). > > > > In any case, it's completely inaccurate to say that each transaction > > requires two revolutions of the drive. Also, if SQLite supports it, > > putting the log files on a seperate set of drives from the tables is > > almost always a win. > > The second sync has to occur before deleting the rollback > journal. Otherwise a powerloss could leave you with both > an incomplete write and a missing rollback journal. > > The rollback journal must always be located in the same > directory as the original database file so that SQLite > will know where to find it. If the rollback journal is > located on a separate volume, that volume might not get > mounted after a power failure of system crash, and you'd > then be left with a corrupted database. Besides that, > how would SQLite know where to look for the rollback > journal if it is off in some other directory someplace? > Remember, SQLite is designed to be robust and easy to > operate which means we cannot control the placement of > the rollback journal using a configuration file. > > -- > D. Richard Hipp <[EMAIL PROTECTED]> > >
Re: [sqlite] Porting SQL to run on a proprietary operating system
If I use memory database, the content will be zeroed when I reboot the equipment. Only memory that is allocated for the filesystem is persistant between power cycles. On 12/29/05, Jay Sprenkle <[EMAIL PROTECTED]> wrote: > If you use ":memory:" as your database name and it will keep the tables in > RAM. > The only drawback there is I believe you can't share data between threads. > Since > you only have one thread that might be just what you need. > > On 12/29/05, Axel Mammes (gmail) <[EMAIL PROTECTED]> wrote: > > Flash will only be used for seldom changed tables or config parameters. > > > > Otherwise I am limited to the battery backed up RAM-based file system. > > > > > > > > -Original Message- > > From: Jay Sprenkle [mailto:[EMAIL PROTECTED] > > Sent: Jueves, 29 de Diciembre de 2005 12:10 p.m. > > To: [EMAIL PROTECTED] > > Subject: Re: [sqlite] Porting SQL to run on a proprietary operating system > > > > I did a project using sqlite under web server CGI. It worked very well and > > was pretty light on required resources. My guess is this will work for you > > as well but you'll need to research some changes to the database engine to > > work against flash drives. I believe several people use in ram databases > > and occasionally flush them to flash storage to prevent 'wearing out' the > > flash prematurely. > > > > On 12/29/05, Axel Mammes (gmail) <[EMAIL PROTECTED]> wrote: > > > I write software for electronic funds transfer terminals. For this project > > > in particular I am using a Verifone Vx570 terminal (www.verifone.com). > > > > > > The platform consists in a 32 bit ARM9 processor with 4-32 MB battery > > backed > > > up RAM and 4-32 flash. The operating system is called Verix. It supports > > > multi-tasking, but multithreading is rather limited. For example a file > > > handle opened in one thread cannot be used by another thread. The compiler > > I > > > will be using is ARM Real View Compiler 2.01. > > > > > > My app will have approximately 80 tables, so I want to add ACID > > transaction > > > support, fast indexed lookups, compressed tables and SQL query support. I > > > don´t want to use standard flat files, since I will end up writing a lot > > > more code. I already made that mistake in a previous project, trying to > > > reinvent the wheel. > > > > > > I will probably have to create a single threaded DB Engine task and use > > > pipes to send messages between tasks, since shared memory is not supported > > > either. I want to keep only one instance of the engine loaded to save > > > memory. > > > > > > Is this the correct approach or should I just dynamically link the sqlite > > > engine to all my tasks and forget about pipes to make my life easier? > > > > > > Any ideas/suggestions? Has anyone here written a port like this? What > > about > > > the memory limitations? Is this too strict? > > > > > > Regards > > > Axel > > > > > > > > > > > > -- > > --- > > The Castles of Dereth Calendar: a tour of the art and architecture of > > Asheron's Call > > http://www.lulu.com/content/77264 > > > > > > > -- > --- > The Castles of Dereth Calendar: a tour of the art and architecture of > Asheron's Call > http://www.lulu.com/content/77264 >
RE: [sqlite] Porting SQL to run on a proprietary operating system
Flash will only be used for seldom changed tables or config parameters. Otherwise I am limited to the battery backed up RAM-based file system. -Original Message- From: Jay Sprenkle [mailto:[EMAIL PROTECTED] Sent: Jueves, 29 de Diciembre de 2005 12:10 p.m. To: [EMAIL PROTECTED] Subject: Re: [sqlite] Porting SQL to run on a proprietary operating system I did a project using sqlite under web server CGI. It worked very well and was pretty light on required resources. My guess is this will work for you as well but you'll need to research some changes to the database engine to work against flash drives. I believe several people use in ram databases and occasionally flush them to flash storage to prevent 'wearing out' the flash prematurely. On 12/29/05, Axel Mammes (gmail) <[EMAIL PROTECTED]> wrote: > I write software for electronic funds transfer terminals. For this project > in particular I am using a Verifone Vx570 terminal (www.verifone.com). > > The platform consists in a 32 bit ARM9 processor with 4-32 MB battery backed > up RAM and 4-32 flash. The operating system is called Verix. It supports > multi-tasking, but multithreading is rather limited. For example a file > handle opened in one thread cannot be used by another thread. The compiler I > will be using is ARM Real View Compiler 2.01. > > My app will have approximately 80 tables, so I want to add ACID transaction > support, fast indexed lookups, compressed tables and SQL query support. I > don´t want to use standard flat files, since I will end up writing a lot > more code. I already made that mistake in a previous project, trying to > reinvent the wheel. > > I will probably have to create a single threaded DB Engine task and use > pipes to send messages between tasks, since shared memory is not supported > either. I want to keep only one instance of the engine loaded to save > memory. > > Is this the correct approach or should I just dynamically link the sqlite > engine to all my tasks and forget about pipes to make my life easier? > > Any ideas/suggestions? Has anyone here written a port like this? What about > the memory limitations? Is this too strict? > > Regards > Axel > > -- --- The Castles of Dereth Calendar: a tour of the art and architecture of Asheron's Call http://www.lulu.com/content/77264
[sqlite] Porting SQL to run on a proprietary operating system
I write software for electronic funds transfer terminals. For this project in particular I am using a Verifone Vx570 terminal (www.verifone.com). The platform consists in a 32 bit ARM9 processor with 4-32 MB battery backed up RAM and 4-32 flash. The operating system is called Verix. It supports multi-tasking, but multithreading is rather limited. For example a file handle opened in one thread cannot be used by another thread. The compiler I will be using is ARM Real View Compiler 2.01. My app will have approximately 80 tables, so I want to add ACID transaction support, fast indexed lookups, compressed tables and SQL query support. I don´t want to use standard flat files, since I will end up writing a lot more code. I already made that mistake in a previous project, trying to reinvent the wheel. I will probably have to create a single threaded DB Engine task and use pipes to send messages between tasks, since shared memory is not supported either. I want to keep only one instance of the engine loaded to save memory. Is this the correct approach or should I just dynamically link the sqlite engine to all my tasks and forget about pipes to make my life easier? Any ideas/suggestions? Has anyone here written a port like this? What about the memory limitations? Is this too strict? Regards Axel
RE: [sqlite] Locking
Does your flat file support ACID transactions? That´s the killer feature fo my app. I want to store financial transactions and I don´t trust normal flat files. -Original Message- From: Dan Petitt [mailto:[EMAIL PROTECTED] Sent: Viernes, 23 de Diciembre de 2005 08:00 p.m. To: sqlite-users@sqlite.org Subject: [sqlite] Locking Are there any plans for sqlite to support row or table level locking, or possibly even Multiversion Concurrency Control, MVCC, its definition being: ~~ While querying a database each transaction sees a snapshot of data (a database version) as it was some time ago, regardless of the current state of the underlying data. This protects the transaction from viewing inconsistent data that could be caused by (other) concurrent transaction updates on the same data rows, providing transaction isolation for each database session. The main advantage to using the MVCC model of concurrency control rather than locking is that in MVCC locks acquired for querying (reading) data do not conflict with locks acquired for writing data, and so reading never blocks writing and writing never blocks reading ~~ The reason being is that we are inserting large amounts of data into the database but we need to read it at the same time, and we need to do this quickly. Some background info: Currently our indexed flat file system is working at speeds in excess of sqlite (or any DB we have found) but sqlite is very close, but the locking issue effectively makes the gui stall whilst the inserts are occuring. Yes they are wrapped up in transactions and we only have a couple of indexes (there are only 5 fields anyway). Also CPU seems to be very high whilst this is going on. We want to use sqlite (if possible) for its flexibility in producing better querying and results than we currently are able to. Thanks for your time. Dan Petitt
RE: [sqlite] ring buffer table
Wouldn´t a SELECT COUNT(*) just read the table header and get the amount of records from there? That should be faster and simpler than maintaning a separate table for the counters. -Original Message- From: Paul Bohme [mailto:[EMAIL PROTECTED] Sent: Viernes, 23 de Diciembre de 2005 02:52 p.m. To: sqlite-users@sqlite.org Subject: Re: [sqlite] ring buffer table Julien LEFORT wrote: >Hi, >I would like to implement a log table with a finite dimension, for exemple a >table with 500 records, and when the last record is set in the table I would >like to come back at the first tuplet and write over the previous value >recorded. I think it's the way SQLite journal is implmented. >Is there any way to declare this table with these properties included, so I >don't have to add code to do this function? >Thanks > > I need something similar, so was planning a couple of simple tricks to keep the overhead low. I want to avoid "select count" queries as much as possible, so how does the following sound: - insert/delete triggers on the table I want to limit the size of - a separate table with a row that contains a single counter, that is incremented and decremented by the above triggers - a process that runs at intervals that checks the counter, and if over the limit trims the appropriate number of records Seems like a reasonable way to keep a table to a limited growth without too much of a hit on every insert. The counter table would be a serious hot spot in other databases, but SQLite's locking is simple enough that it doesn't seem like it will be a problem. -P
