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 >
