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
