Sqlite on an embedded system

I have a database file that is generated on a PC using Sqlite. This file is then transferred to an ARM7 based embedded system without an operating system. The embedded system must access this database, but does not need to update it.

I have been trying to get sqlite3 small enough for the embedded system, but so far I cannot get the application size under 256 Kbytes (my limit).

Has anyone been able to get sqlite3 down to this size? Is there other software that I can use to read this database?

EDIT: I am trying 开发者_Python百科to access the database using C. This would be done using the sqlite3_exec() function.

There are two tables. One table has an ID and text, the second an ID, link to ID of first table, text, and status value. The only access required is by ID or partial text on the first table, and by ID on the second table.

Perhaps there is some standalone code that can be used to access the database?

The smallest sqlite3 I came up with was 327 KBytes (for PowerPC), which was sufficient for the system so I stopped trying to make it smaller. This was the full sqlite3 CLI binary, the C APIs alone would have been somewhat smaller.

I had set SQLITE_OMIT_AUTHORIZATION, SQLITE_OMIT_EXPLAIN, SQLITE_OMIT_PROGRESS_CALLBACK, and SQLITE_OMIT_TCL_VARIABLE to trim the size of the binary, and used -Os to get it to that size.

If you don't need the full power of SQL it might be interesting to look into alternative solutions, like Berkeley DB.

You may want to have a look at cdb it is great for 'constant' data, the code is opensource and will compile to tiny executables, you can even gut it to get the exe smaller. Under 10k should be easy. google cdb

Can you export the database file to a XML or text or another "flat" file? That's much easier to work with in an embedded environment.

I'd try first with sqlite2, it might be leaner (or not). If that doesn't help, I'd say go with your own binary encoding.

Unless your data file is really big, what you lose on SQLite great optimisations, you'll gain by not using SQL.

Of course, use appropriate data structures (most probably a B*Tree or similar).