John Stanton <[EMAIL PROTECTED]> wrote:
> Rollback is a problem with simpler software.
>
> You are basically specifying Sqlite in your requirements, and it does
> all that wiith a small footprint based on the capability.
>
> You might contact Dr Hipp and enquire about a commercial version
Rollback is a problem with simpler software.
You are basically specifying Sqlite in your requirements, and it does
all that wiith a small footprint based on the capability.
You might contact Dr Hipp and enquire about a commercial version of
Sqlite which strips out the SQL compiler and uses pr
I am an extreme newbie at this and I am open to suggestions:
My requirements are:
Smallest footprint possible
ACID requirements (transactional rollback a must)
Be able to create tables with fields that have name/value pairs.
Not sure what else!
If a dBase derivative meets these requireme
On 31/03/07, Cesar Rodas <[EMAIL PROTECTED]> wrote:
On 30/03/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I'm looking at using Sqlite as a storage backend for a program.
> > > > Using SQL is a little bit overkill
> > >
> > > why bother with
On 30/03/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
<[EMAIL PROTECTED]> wrote:
> > >
> > > I'm looking at using Sqlite as a storage backend for a program.
> > > Using SQL is a little bit overkill
> >
> > why bother with SQLite then? Use the right tool for the job
> > -- use BerkeleyDB.
Why not implement a simple index file system like one of the DBase
derivatives? If you have no OS you will find porting something like
Sqlite or Berkely DB a challenge. If you are not looking for SQL then
you can achieve your goal in maybe 20K of memory.
[EMAIL PROTECTED] wrote:
P Kisho
[EMAIL PROTECTED] wrote:
> <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I'm looking at using Sqlite as a storage backend for a program.
> > > > Using SQL is a little bit overkill
> > >
> > > why bother with SQLite then? Use the right tool for the job
> > > -- use BerkeleyDB.
> > >
> >
>
<[EMAIL PROTECTED]> wrote:
> > >
> > > I'm looking at using Sqlite as a storage backend for a program.
> > > Using SQL is a little bit overkill
> >
> > why bother with SQLite then? Use the right tool for the job
> > -- use BerkeleyDB.
> >
>
> Size is a constraint for me.
> I see that SQLite
P Kishor <[EMAIL PROTECTED]> wrote:
> On 3/29/07, Ludvig Strigeus <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I'm looking at using Sqlite as a storage backend for a program. Using SQL is
> > a little bit overkill and much more than we need. How complicated would it
> > be to interface to the
On 3/29/07, Ludvig Strigeus <[EMAIL PROTECTED]> wrote:
Hi,
I'm looking at using Sqlite as a storage backend for a program. Using SQL is
a little bit overkill and much more than we need. How complicated would it
be to interface to the btree subsystem directly? Sqlite seems very modular
from the l
[EMAIL PROTECTED] wrote:
Martin Jenkins <[EMAIL PROTECTED]> wrote:
Very true. Furthermore, the B-Tree interface layer is not a part
of the published API and as such it is subject to change without
notice and between point releases.
I nearly said that the B-Tree interface was unpublished bu
Martin Jenkins <[EMAIL PROTECTED]> wrote:
> Ludvig Strigeus wrote:
> > Hi,
> >
> > I'm looking at using Sqlite as a storage backend for a program. Using
> > SQL is a little bit overkill...
>
> ... I reckon learning that SQL would be a lot easier than
> learning to use and/or coding against the B
Ludvig Strigeus wrote:
Hi,
I'm looking at using Sqlite as a storage backend for a program. Using
SQL is
a little bit overkill and much more than we need. How complicated would it
be to interface to the btree subsystem directly? Sqlite seems very modular
from the looks of it, but has anyone att
Hi,
I'm looking at using Sqlite as a storage backend for a program. Using SQL is
a little bit overkill and much more than we need. How complicated would it
be to interface to the btree subsystem directly? Sqlite seems very modular
from the looks of it, but has anyone attempted anything like this
14 matches
Mail list logo