DeviceSQL

[John Stanton]

I received an email promoting a DeviceSQL web presentation. It
specifically targets Sqlite and promises 5X performance.

For those interested -

DeviceSQL vs. SQLite: Which Gets You the Most Efficient Embedded Database?
DATE: Thursday, December 13th, 2007
TIME: Noon PST, 3:00 PM EST
DURATION: 50 minutes + Q & A
Register: http://seminar2.techonline.com/registration/distrib.cgi?s=1191&d=1700
Who Should Attend: Software Engineers, Software Architects, Software Engineering Managers
Webinar Overview
Reliably processing, searching and managing growing amounts of data is driving many embedded developers to use third-party data management software such as DeviceSQL or SQLite. However, a critical issue for these technologies is their efficiency in terms of performance and memory usage, especially when they’re being used to replace hand-coded databases in resource-constrained systems.
While SQLite is widely-known, many users are frustrated by not being able to meet stringent performance and/or memory size goals with SQLite, particularly in applications with a sub-2 GHz CPU. In this webinar you’ll learn how DeviceSQL, a next-generation technology for managing data, provides 5x the performance of SQLite while yielding a smaller memory footprint. Also, a DeviceSQL user, TV Guide, will share how they were able to meet their aggressive design goals for managing electronic program guide (EPG) data. This seminar is for engineers who are currently using SQLite or anyone considering an embedded database technology.

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[d***@public.gmane.org]

Post by John Stanton
I received an email promoting a DeviceSQL web presentation. It
specifically targets Sqlite and promises 5X performance.

If you view their web presentation and/or try out Encirq's
products, I would be very interested to hear your impressions.
Even better would be if you could blog about it.

Encirq has for years been running Google Adsense ads claiming
to be 20x faster than SQLite. (Dunno why they have now reduced
that claim to 5x faster.) But I have never yet seen an
independent confirmation of this. Nor even have I been able
to find anybody who is actually using DeviceSQL in a product.
Web searches turn up nothing but marketing literature coming
directly or indirectly from Encirq. Some independent analysis
(regardless of whether it is favorable or unfavorable to SQLite)
would be appreciated.

My understanding of DeviceSQL is:

* It is NOT transactional. There is no such thing as ROLLBACK.
* If you lose power during a write, your database is toast.
* If your database schema changes, you have to recompile
your application.
* The database file format changes depending on the schema.
* DeviceSQL is not a general-purpose database engine. You
compile SQL statements into C code on a development
workstation, then compile the C code for your embedded
device.

I can imagine circumstances where the DeviceSQL approach,
while much less flexible and forgiving than SQLite, might
be a better way to go, depending on what you are trying to
do. But I have not gotten good vibes from Encirq as a
company. And I have no idea how reliable the DeviceSQL
product is. I would really appreciate your thoughts on
that subject.

--
D. Richard Hipp <***@hwaci.com>


-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[John Stanton]

Post by d***@public.gmane.org

Post by John Stanton
I received an email promoting a DeviceSQL web presentation. It
specifically targets Sqlite and promises 5X performance.

If you view their web presentation and/or try out Encirq's
products, I would be very interested to hear your impressions.
Even better would be if you could blog about it.
Encirq has for years been running Google Adsense ads claiming
to be 20x faster than SQLite. (Dunno why they have now reduced
that claim to 5x faster.) But I have never yet seen an
independent confirmation of this. Nor even have I been able
to find anybody who is actually using DeviceSQL in a product.
Web searches turn up nothing but marketing literature coming
directly or indirectly from Encirq. Some independent analysis
(regardless of whether it is favorable or unfavorable to SQLite)
would be appreciated.
* It is NOT transactional. There is no such thing as ROLLBACK.
* If you lose power during a write, your database is toast.
* If your database schema changes, you have to recompile
your application.
* The database file format changes depending on the schema.
* DeviceSQL is not a general-purpose database engine. You
compile SQL statements into C code on a development
workstation, then compile the C code for your embedded
device.
I can imagine circumstances where the DeviceSQL approach,
while much less flexible and forgiving than SQLite, might
be a better way to go, depending on what you are trying to
do. But I have not gotten good vibes from Encirq as a
company. And I have no idea how reliable the DeviceSQL
product is. I would really appreciate your thoughts on
that subject.
--

Your earlier description of DeviceSQL intrigued me. In general claims
of "20x" or even "5x" imply either serious deficiencies in the compared
product or a generous dose of snake oil in the challenger. Since we
know the Sqlite code and use it without encountering serious
deficiencies, I smell snake, but shall look at the presentation and ask
some questions if possible and report back.

Like you, I have been unable to uncover any concrete documentation or
reviews of this product.

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Joe Wilson]

Be careful about speculative comments.

For all anyone knows, said product could use SQLite internally with
a couple of proprietary optimizations here and there that may make it
faster in specific cases.

The sqlite public domain license would allow that sort of thing.


____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[d***@public.gmane.org]

Post by Joe Wilson
Be careful about speculative comments.
For all anyone knows, said product could use SQLite internally with
a couple of proprietary optimizations here and there that may make it
faster in specific cases.
The sqlite public domain license would allow that sort of thing.

Because of the radically different architectures of SQLite
and DeviceSQL, it seems unlikely that they share a common
core. Though, I suppose anything is possible...

--
D. Richard Hipp <***@hwaci.com>


-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[steveweick]

Richard has it right this time. Today DeviceSQL uses no SQLite code. One of
the things we might consider is bolting the SQLite parser/front end to our
table engine, in theory to get the both worlds. Just an idea at the moment.

Steve

Post by d***@public.gmane.org

Post by Joe Wilson
Be careful about speculative comments.
For all anyone knows, said product could use SQLite internally with
a couple of proprietary optimizations here and there that may make it
faster in specific cases.
The sqlite public domain license would allow that sort of thing.

Because of the radically different architectures of SQLite
and DeviceSQL, it seems unlikely that they share a common
core. Though, I suppose anything is possible...
--
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------

[James Steward]

Post by steveweick
Richard has it right this time. Today DeviceSQL uses no SQLite code. One of
the things we might consider is bolting the SQLite parser/front end to our
table engine, in theory to get the both worlds. Just an idea at the moment.

Such an interesting discussion to be following. I must say though, it
seems DeviceSQL has opened the door to speculation due to
unsubstantiated claims in advertising, as far as I see it. IMHO, so
long as there is no independent, unbiased, side by side test results
presented somewhere by some reliable source, there will always be some
room for "ifs" and "buts" by both sides.

Maybe DeviceSQL should go open source, so the public can judge for them
selves the qualities of the two products. There would still be money to
be made from paid support. Who knows, both parties could benefit, and
customers too. At least there'd be a clearer view of the pros and cons.

There is something to be said for a product being open source, that is
the code is scrutinized by the world. Closed shop code can possibly
still be very good, but without seeing it, how would we know? Reminds
me of a story about a cat: dead or alive, we won't know until we open
the box it's in, and prior to that, is it only half dead?

One only has to look at the MSDN code examples to see the ugliness of
closed source code development...(sorry Bill)

JS.

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[steveweick]

Hi James,

You raise some interesting points. There is nothing secret about the
benchmarks. We will make the code that was used to run benchmarks available
to anyone who wants to see it and verify results. If you want to find a
third party to verify, be my guest. The benchmark report goes into some
depth on the design and rationale for the benchmark. Frankly, as much as I
like the idea about taking DeviceSQL open source, you don't need to do so,
just to verify performance claims.

Do you need to read the code to verify reliability as your next few
sentences seems to imply? For that to be true, the reader would have to be
able to spot bugs through inspection. While that is certainly one way to
spot bugs, I seriously doubt that any shop would rely on code inspection,
when millions of dollars of potential recall costs are on the line.

In fact the SQLite marketing does not rely on code inspection as its
argument for why the code is reliable. Check it out.

All of that said, I do admire the elegance of the SQLite code. It makes
entertaining reading. Unfortunately elegance does not translate into
performance or reliability.

Regards,

Steve

Post by James Steward

Post by steveweick
Richard has it right this time. Today DeviceSQL uses no SQLite code. One of
the things we might consider is bolting the SQLite parser/front end to our
table engine, in theory to get the both worlds. Just an idea at the moment.

Such an interesting discussion to be following. I must say though, it
seems DeviceSQL has opened the door to speculation due to
unsubstantiated claims in advertising, as far as I see it. IMHO, so
long as there is no independent, unbiased, side by side test results
presented somewhere by some reliable source, there will always be some
room for "ifs" and "buts" by both sides.
Maybe DeviceSQL should go open source, so the public can judge for them
selves the qualities of the two products. There would still be money to
be made from paid support. Who knows, both parties could benefit, and
customers too. At least there'd be a clearer view of the pros and cons.
There is something to be said for a product being open source, that is
the code is scrutinized by the world. Closed shop code can possibly
still be very good, but without seeing it, how would we know? Reminds
me of a story about a cat: dead or alive, we won't know until we open
the box it's in, and prior to that, is it only half dead?
One only has to look at the MSDN code examples to see the ugliness of
closed source code development...(sorry Bill)
JS.
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------

[dcharno]

I would like to recommend that Encriq create a forum or mailing list of
their own for those who are interesting in learning more. For me, what
might be an interesting product is quickly being overshadowed by this
thread.

Post by steveweick
You raise some interesting points. There is nothing secret about the
benchmarks. We will make the code that was used to run benchmarks available
to anyone who wants to see it and verify results. If you want to find a
third party to verify, be my guest. The benchmark report goes into some
depth on the design and rationale for the benchmark. Frankly, as much as I
like the idea about taking DeviceSQL open source, you don't need to do so,
just to verify performance claims.
Do you need to read the code to verify reliability as your next few
sentences seems to imply? For that to be true, the reader would have to be
able to spot bugs through inspection. While that is certainly one way to
spot bugs, I seriously doubt that any shop would rely on code inspection,
when millions of dollars of potential recall costs are on the line.
In fact the SQLite marketing does not rely on code inspection as its
argument for why the code is reliable. Check it out.
All of that said, I do admire the elegance of the SQLite code. It makes
entertaining reading. Unfortunately elegance does not translate into
performance or reliability.
Regards,
Steve

Post by James Steward

Post by steveweick
Richard has it right this time. Today DeviceSQL uses no SQLite code. One of
the things we might consider is bolting the SQLite parser/front end to our
table engine, in theory to get the both worlds. Just an idea at the moment.

Such an interesting discussion to be following. I must say though, it
seems DeviceSQL has opened the door to speculation due to
unsubstantiated claims in advertising, as far as I see it. IMHO, so
long as there is no independent, unbiased, side by side test results
presented somewhere by some reliable source, there will always be some
room for "ifs" and "buts" by both sides.
Maybe DeviceSQL should go open source, so the public can judge for them
selves the qualities of the two products. There would still be money to
be made from paid support. Who knows, both parties could benefit, and
customers too. At least there'd be a clearer view of the pros and cons.
There is something to be said for a product being open source, that is
the code is scrutinized by the world. Closed shop code can possibly
still be very good, but without seeing it, how would we know? Reminds
me of a story about a cat: dead or alive, we won't know until we open
the box it's in, and prior to that, is it only half dead?
One only has to look at the MSDN code examples to see the ugliness of
closed source code development...(sorry Bill)
JS.
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Birt, Jeffrey]

I concur. Quite an interesting marketing strategy; Join you competitors'
mailing lists and trash talk them. LOL

-----Original Message-----
From: dcharno [mailto:dcharno-***@public.gmane.org]
Sent: Thursday, December 13, 2007 8:30 PM
To: sqlite-users-CzDROfG0BjIdnm+***@public.gmane.org
Subject: Re: [sqlite] DeviceSQL

I would like to recommend that Encriq create a forum or mailing list of
their own for those who are interesting in learning more. For me, what
might be an interesting product is quickly being overshadowed by this
thread.

Post by steveweick
You raise some interesting points. There is nothing secret about the
benchmarks. We will make the code that was used to run benchmarks available
to anyone who wants to see it and verify results. If you want to find a
third party to verify, be my guest. The benchmark report goes into some
depth on the design and rationale for the benchmark. Frankly, as much as I
like the idea about taking DeviceSQL open source, you don't need to do so,
just to verify performance claims.
Do you need to read the code to verify reliability as your next few
sentences seems to imply? For that to be true, the reader would have to be
able to spot bugs through inspection. While that is certainly one way to
spot bugs, I seriously doubt that any shop would rely on code

inspection,

Post by steveweick
when millions of dollars of potential recall costs are on the line.
In fact the SQLite marketing does not rely on code inspection as its
argument for why the code is reliable. Check it out.
All of that said, I do admire the elegance of the SQLite code. It makes
entertaining reading. Unfortunately elegance does not translate into
performance or reliability.
Regards,
Steve

Post by James Steward

Post by steveweick
Richard has it right this time. Today DeviceSQL uses no SQLite

code. One

Post by steveweick

Post by James Steward

Post by steveweick
of
the things we might consider is bolting the SQLite parser/front end

to

Post by steveweick

Post by James Steward

Post by steveweick
our
table engine, in theory to get the both worlds. Just an idea at the moment.

Such an interesting discussion to be following. I must say though, it
seems DeviceSQL has opened the door to speculation due to
unsubstantiated claims in advertising, as far as I see it. IMHO, so
long as there is no independent, unbiased, side by side test results
presented somewhere by some reliable source, there will always be some
room for "ifs" and "buts" by both sides.
Maybe DeviceSQL should go open source, so the public can judge for them
selves the qualities of the two products. There would still be money to
be made from paid support. Who knows, both parties could benefit, and
customers too. At least there'd be a clearer view of the pros and cons.
There is something to be said for a product being open source, that is
the code is scrutinized by the world. Closed shop code can possibly
still be very good, but without seeing it, how would we know?

Reminds

Post by steveweick

Post by James Steward
me of a story about a cat: dead or alive, we won't know until we open
the box it's in, and prior to that, is it only half dead?
One only has to look at the MSDN code examples to see the ugliness of
closed source code development...(sorry Bill)
JS.

------------------------------------------------------------------------
-----
------------------------------------------------------------------------
-----
------------------------------------------------------------------------
-----
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
------------------------------------------------------------------------
-----


-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[steveweick]

Good idea... I'll pass it along to the right folks. Meanwhile, if anyone has
further questions or comments, please feel free to write me here (if they
think the group would be interested) or at steve.weick-s82n+LaTkdyXj1p+***@public.gmane.org

Steve

I would like to recommend that Encriq create a forum or mailing list of
their own for those who are interesting in learning more. For me, what
might be an interesting product is quickly being overshadowed by this
thread.

[John Stanton]

I unfortunately missed the Encirq webinar thanks to a project commitment
but have taken the time to download the Encirq demo and try to make good
the loss. It has some user examples in source code which give an idea
of how it functions, but the information on the product is sparse so it
was not possible to get an idea of the mechanics of indices, paging etc.

What I saw was a well conceived product to build embedded software. It
seems to be a compiler which transforms Encirq's version of PL/SQL into
C statements which are then compiled into a library of data manipulation
functions for use in the application. The demo uses gcc. Encirq has a
means of including "storage modules" to handle different forms of
persistent storage. DeviceSQL appears to handle transactions and
rollbacks. There is no information I could find about ACID functionality.

I shall prepare some benchmarks against Sqlite once I figure out a
suitable method. Since DeviceSQl has no SQL compiler the Sqlite will
need to have prepared statements and binding to provide an apples to
apples comparison. The Encirq introductory application example is by
necessity trivial and small and not suited to a benchmark.

DeviceSQL is not suitable for general purpose SQL processing, unlike
Sqlite, and should only be compared as an alternative in deeply embedded
applications so the only useful comparison is one which looks like a
cell phone, microwave oven or a TV set top box.

I can imagine that a version of Sqlite which does not include its SQL
compiler and which uses precompiled VDBE code would provide similar
functionality to DeviceSQL, particularly if the Sqlite compiler were
extended to generate VDBE from PL/SQl. I can imagine that the higher
information density of the VDBE code could deliver the advantage =of a
smaller memory footprint.

For Steve Weick - I note your very strong resume and would imagine that
your comprehensive experience would lead you to introduce a less
secretive policy as to revealing the capabilities of your product.

Post by steveweick
Good idea... I'll pass it along to the right folks. Meanwhile, if anyone has
further questions or comments, please feel free to write me here (if they
Steve
I would like to recommend that Encriq create a forum or mailing list of
their own for those who are interesting in learning more. For me, what
might be an interesting product is quickly being overshadowed by this
thread.

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Dennis Cote]

Post by John Stanton
DeviceSQL is not suitable for general purpose SQL processing, unlike
Sqlite, and should only be compared as an alternative in deeply
embedded applications so the only useful comparison is one which looks
like a cell phone, microwave oven or a TV set top box.

The application doesn't necessarily have to look like a microwave. :-)

It could be any application that uses a fixed set of predetermined SQL
statements to perform its operations. My primary application does
exactly that using SQLite with all statements prepared and cached as
needed. It runs on a standard PC under Windows. We have no need for
executing arbitrary, runtime generated, or user supplied SQL as many
other applications do. Every SQL statement that can be executed is known
before the application starts.

Post by John Stanton
I can imagine that a version of Sqlite which does not include its SQL
compiler and which uses precompiled VDBE code would provide similar
functionality to DeviceSQL, particularly if the Sqlite compiler were
extended to generate VDBE from PL/SQl. I can imagine that the higher
information density of the VDBE code could deliver the advantage =of a
smaller memory footprint.

I thought that this already existed as a commercial product that Richard
offered, but I can't find any reference to it on the paid support page
at http://www.hwaci.com/sw/sqlite/prosupport.html. My recollection was
an offline compiler that ran on a PC and generated VDBE code to execute
SQL statements, along with source code for a runtime execution engine
that would execute those pre-compiled statements. The execution engine
could be built for any target, and was much smaller than SQLite because
it eliminated the parser and code generator functionality. Does this
exist, or was I just imagining it?

Dennis Cote

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[d***@public.gmane.org]

Post by Dennis Cote

Post by John Stanton
I can imagine that a version of Sqlite which does not include its SQL
compiler and which uses precompiled VDBE code would provide similar
functionality to DeviceSQL, particularly if the Sqlite compiler were
extended to generate VDBE from PL/SQl. I can imagine that the higher
information density of the VDBE code could deliver the advantage =of a
smaller memory footprint.

I thought that this already existed as a commercial product that Richard
offered, but I can't find any reference to it on the paid support page
at http://www.hwaci.com/sw/sqlite/prosupport.html. My recollection was
an offline compiler that ran on a PC and generated VDBE code to execute
SQL statements, along with source code for a runtime execution engine
that would execute those pre-compiled statements. The execution engine
could be built for any target, and was much smaller than SQLite because
it eliminated the parser and code generator functionality. Does this
exist, or was I just imagining it?

That would be the Serialized Statement Extension, SSE.
The SSE provides the programmer with two new APIs:

int sqlite3_serialize(sqlite3_stmt*, void**, int*);
int sqlite3_deserialize(sqlite3*, void*, int, sqlite3_stmt**);

The first routine takes an SQL statement that was generated by
sqlite3_prepare() and converts it into a form that can be stored
on disk or compiled into a program. The second routine does the
reverse; it takes the serialization of a statement and converts it
back into a working SQL statement that can be used just like any
other statement created by sqlite3_prepare().

You compile SQLite normally on your development workstation, but
for you embedded target you add -DSQLITE_OMIT_PARSER to leave off
the parser. By omitting other optional features (date/time functions,
views, triggers) you can get the size of the library down to the 70KiB
range or less.

On a workstation, you can sqlite3_prepare() statements, then hand
them to sqlite3_serialize(). The results can be hard coded into
C programs to be manually deserialized later, if you like, though
that is a lot of work. A simpler approach is to use the special
sqlite_statement table:

CREATE TABLE sqlite_statement(
id INTEGER PRIMARY KEY,
sql TEXT,
serial BLOB
);

A new API is available that will automatically extract and deserialize
an SQL statement from the sqlite_statement table given its id number:

int sqlite3_fetch_statement(sqlite3*, int id, sqlite3_stmt**);

The idea here is that the SQL statements needed by an application can
be inserted as plain text into the sqlite_statement table. For
example:

INSERT INTO sqlite_statement(sql) VALUES('SELECT * FROM table1');

After many such statements are inserted, they can all be serialized
as follows:

UPDATE sqlite_statement SET serial = sqlite_serialize(sql,id);

Then the complete database can be moved from the development platform
over to the embedded device and the embedded device can use the
sqlite3_fetch_statement() API to extract the statements it needs to
execute.

To be useful, your precompiled statements will normally contain
parameters (ex: "INSERT INTO tx VALUES(?,?,?)") and the embedded
application will using sqlite3_bind_xxx() interfaces to attach
values to these parameter prior to invoking sqlite3_step().

The SSE has not been kept current with the base SQLite. But if there
is interest, we could resurrect it easily enough.

--
D. Richard Hipp <***@hwaci.com>


-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Shawn Wilsher]

Post by d***@public.gmane.org
That would be the Serialized Statement Extension, SSE.
int sqlite3_serialize(sqlite3_stmt*, void**, int*);
int sqlite3_deserialize(sqlite3*, void*, int, sqlite3_stmt**);
The first routine takes an SQL statement that was generated by
sqlite3_prepare() and converts it into a form that can be stored
on disk or compiled into a program. The second routine does the
reverse; it takes the serialization of a statement and converts it
back into a working SQL statement that can be used just like any
other statement created by sqlite3_prepare().
You compile SQLite normally on your development workstation, but
for you embedded target you add -DSQLITE_OMIT_PARSER to leave off
the parser. By omitting other optional features (date/time functions,
views, triggers) you can get the size of the library down to the 70KiB
range or less.
On a workstation, you can sqlite3_prepare() statements, then hand
them to sqlite3_serialize(). The results can be hard coded into
C programs to be manually deserialized later, if you like, though
that is a lot of work. A simpler approach is to use the special
CREATE TABLE sqlite_statement(
id INTEGER PRIMARY KEY,
sql TEXT,
serial BLOB
);
A new API is available that will automatically extract and deserialize
int sqlite3_fetch_statement(sqlite3*, int id, sqlite3_stmt**);
The idea here is that the SQL statements needed by an application can
be inserted as plain text into the sqlite_statement table. For
INSERT INTO sqlite_statement(sql) VALUES('SELECT * FROM table1');
After many such statements are inserted, they can all be serialized
UPDATE sqlite_statement SET serial = sqlite_serialize(sql,id);
Then the complete database can be moved from the development platform
over to the embedded device and the embedded device can use the
sqlite3_fetch_statement() API to extract the statements it needs to
execute.
To be useful, your precompiled statements will normally contain
parameters (ex: "INSERT INTO tx VALUES(?,?,?)") and the embedded
application will using sqlite3_bind_xxx() interfaces to attach
values to these parameter prior to invoking sqlite3_step().
The SSE has not been kept current with the base SQLite. But if there
is interest, we could resurrect it easily enough.

I think that Mozilla may find that useful. I think it came up about a
month ago with some places code (new bookmark back-end).

Seth, I think it was you and Mano that were talking about this. Would
this be useful for us?

Cheers,

Shawn

Post by d***@public.gmane.org
--
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Nicolas Williams]

Post by d***@public.gmane.org
That would be the Serialized Statement Extension, SSE.

Would it be useful to generate human-readable VDBE "assemply"?

Or, how do you develop parser changes that involve new VDBE code
patterns?

Just curious,

Nico

[Nicolas Williams]

Post by Nicolas Williams

Post by d***@public.gmane.org
That would be the Serialized Statement Extension, SSE.

Would it be useful to generate human-readable VDBE "assemply"?

I meant "assembly".

Post by Nicolas Williams
Or, how do you develop parser changes that involve new VDBE code
patterns?

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[d***@public.gmane.org]

Post by Nicolas Williams

Post by d***@public.gmane.org
That would be the Serialized Statement Extension, SSE.

Would it be useful to generate human-readable VDBE "assemply"?
Or, how do you develop parser changes that involve new VDBE code
patterns?

The EXPLAIN option generates human-readable assembly. We
use EXPLAIN extensively when debugging and enhancing.

I should point out that while we work very hard to keep the
file format for SQLite stable, we make no such effort with
the VDBE. The opcodes can and do change significantly between
point releases. Hence the serializations generated by one
version of SQLite can only be interpreted by that exact same
version of SQLite.

Case in point: A new opcode has been added for the pending 3.5.4
release. And this caused many of the other opcodes to be
automatically renumbered. A serialization created for 3.5.3
has little hope of running on 3.5.4.

--
D. Richard Hipp <***@hwaci.com>


-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Noah Hart]

Why can't new OP codes be simply added to the end, so that the
serializations will always work?

Noah

-----Original Message-----
From: drh-***@public.gmane.org [mailto:drh-***@public.gmane.org]
Sent: Friday, December 14, 2007 8:20 AM
To: sqlite-users-CzDROfG0BjIdnm+***@public.gmane.org
Subject: Re: [sqlite] DeviceSQL
Importance: High

Case in point: A new opcode has been added for the pending 3.5.4
release. And this caused many of the other opcodes to be
automatically renumbered. A serialization created for 3.5.3
has little hope of running on 3.5.4.

--
D. Richard Hipp <drh-***@public.gmane.org>




CONFIDENTIALITY NOTICE:
This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.




-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[d***@public.gmane.org]

Post by Noah Hart
Why can't new OP codes be simply added to the end, so that the
serializations will always work?

We do not often add new opcodes. The usual change is to
alter the meaning and operation of existing opcodes. We
also delete existing opcodes about as often as we add new
ones.

Furthermore, the opcode numbers are not chosen haphazardly.
The opcode numbers are in many cases carefully aligned with
token numbers in the parser in order to make the code
generate smaller. And opcodes that are often used together
within switch statements are grouped together numerically
so that the jump tables used to implement the switch()
statements are smaller - resulting in a smaller executable.

--
D. Richard Hipp <***@hwaci.com>


-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[John Stanton]

This post might be inappropriate. Click to display it.

[Nicolas Williams]

Post by d***@public.gmane.org
The EXPLAIN option generates human-readable assembly. We
use EXPLAIN extensively when debugging and enhancing.

Yes, but there's no assembler for EXPLAIN output, is there?

Also, the only way to deal with EXPLAIN is to step through its results
-- there's no way to directly insert its output rows into a temporary
table and then use a select using group_concat() to generate a single
string consisting of the VDBE assembly. It is, however, possible to use
.mode insert and explain to generate INSERT statements that can then be
used to insert the VDBE program into a table, and then one can do more
interesting things (I suppose one could even write an assembler in SQL).

Post by d***@public.gmane.org
I should point out that while we work very hard to keep the
file format for SQLite stable, we make no such effort with
the VDBE. The opcodes can and do change significantly between
point releases. Hence the serializations generated by one
version of SQLite can only be interpreted by that exact same
version of SQLite.

Right.

Nico

[d***@public.gmane.org]

Post by Dennis Cote
It could be any application that uses a fixed set of predetermined SQL
statements to perform its operations. My primary application does
exactly that using SQLite with all statements prepared and cached as
needed. It runs on a standard PC under Windows. We have no need for
executing arbitrary, runtime generated, or user supplied SQL as many
other applications do. Every SQL statement that can be executed is known
before the application starts.

Your application uses a fixed set of SQL statements now. But
that set of statements might change in the next release. Or you
might change or modify a table, or add an index.

A key feature SQLite is that these changes preserve the file
format. With other systems, when you change the schema the
file format changes with it.

One of the ideas I try to push is SQLite as an Application File
Format. The idea is that you put your information in an SQLite
database file and it is then readable by diverse, general-purpose
tools, and across multiple releases. Sure, the schema might
change from one release to the next, but the data is still
easily accessible.

In order to promote this idea, we are very careful to make sure
that the SQLite file format does not change in ways that are
not backwards compatible. Our goal is to make sure that the
information you put into an SQLite database today is still
easily accessible using general-purpose tools after 20 or 30
years.

Further to this goal, watch for detailed specficiations of the
SQLite file format to appear in 2008.

--
D. Richard Hipp <***@hwaci.com>


-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Dennis Cote]

Post by d***@public.gmane.org

Post by Dennis Cote
It could be any application that uses a fixed set of predetermined SQL
statements to perform its operations. My primary application does
exactly that using SQLite with all statements prepared and cached as
needed. It runs on a standard PC under Windows. We have no need for
executing arbitrary, runtime generated, or user supplied SQL as many
other applications do. Every SQL statement that can be executed is known
before the application starts.

Your application uses a fixed set of SQL statements now. But
that set of statements might change in the next release. Or you
might change or modify a table, or add an index.
A key feature SQLite is that these changes preserve the file
format. With other systems, when you change the schema the
file format changes with it.

Yes, of course. We can also generally use SQL to "upgrade" existing
database files to the new schema quite easily using SQLite.

Post by d***@public.gmane.org
One of the ideas I try to push is SQLite as an Application File
Format. The idea is that you put your information in an SQLite
database file and it is then readable by diverse, general-purpose
tools, and across multiple releases. Sure, the schema might
change from one release to the next, but the data is still
easily accessible.

The biggest problem I see with this concept right now is that if you use
any custom functions or collations you really can't work with your
database using diverse, general purpose tools. If you have triggers or
views that call these custom functions then you have difficulties
accessing the data from any other application, especially third party
database browsers etc.

That is the principal reason I think it would be very useful to extend
the base set of functions and collations that are universally available
to all applications using SQLite to access a database file. Things like
graphical browser applications, where code size really isn't an issue,
would always include the full set of functions. Users on space
restricted embedded systems could easily eliminate the functions they
aren't using to minimize the code space for their targets. The size of
the SQLite shared library or DLL is normally not a concern on
workstations with ram measured in GB and disks that are on the order of TB.

Custom functions are a great idea, but it would be better to have a
wider selection of standard functions so that users only needed to
resort to custom functions in rare cases (or at least less often).

Post by d***@public.gmane.org
In order to promote this idea, we are very careful to make sure
that the SQLite file format does not change in ways that are
not backwards compatible. Our goal is to make sure that the
information you put into an SQLite database today is still
easily accessible using general-purpose tools after 20 or 30
years.
Further to this goal, watch for detailed specficiations of the
SQLite file format to appear in 2008.

I'm glad to hear that, and look forward to seeing it.

Dennis Cote


-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[John Stanton]

Dennis, your application may not be a microwave oven but it does appear
to be "deeply embedded" as opposed to a general purpose DB server which
handles generic queries.

I was aware of the runtime only version of Sqlite, but is it not
directly comparable to DeviceSQL unless the external compiler handles
not only SQL but also PL/SQL. The addition of the command language
allows for creating a library of data manipulation functions rather than
just embedded SQL. My point was that the DeviceSQL approach could be
used with Sqlite to produce a smaller footprint embedded product and
that such a product has the potential of being less memory hungry than
DeviceSQL simply by virtue of the higher information density of the VDBE
target code compared to native machine instructions.

Post by Dennis Cote

Post by John Stanton
DeviceSQL is not suitable for general purpose SQL processing, unlike
Sqlite, and should only be compared as an alternative in deeply
embedded applications so the only useful comparison is one which looks
like a cell phone, microwave oven or a TV set top box.

The application doesn't necessarily have to look like a microwave. :-)
It could be any application that uses a fixed set of predetermined SQL
statements to perform its operations. My primary application does
exactly that using SQLite with all statements prepared and cached as
needed. It runs on a standard PC under Windows. We have no need for
executing arbitrary, runtime generated, or user supplied SQL as many
other applications do. Every SQL statement that can be executed is known
before the application starts.

Post by John Stanton
I can imagine that a version of Sqlite which does not include its SQL
compiler and which uses precompiled VDBE code would provide similar
functionality to DeviceSQL, particularly if the Sqlite compiler were
extended to generate VDBE from PL/SQl. I can imagine that the higher
information density of the VDBE code could deliver the advantage =of a
smaller memory footprint.

I thought that this already existed as a commercial product that Richard
offered, but I can't find any reference to it on the paid support page
at http://www.hwaci.com/sw/sqlite/prosupport.html. My recollection was
an offline compiler that ran on a PC and generated VDBE code to execute
SQL statements, along with source code for a runtime execution engine
that would execute those pre-compiled statements. The execution engine
could be built for any target, and was much smaller than SQLite because
it eliminated the parser and code generator functionality. Does this
exist, or was I just imagining it?
Dennis Cote
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Samuel R. Neff]

-----Original Message-----
From: John Stanton [mailto:johns-***@public.gmane.org]
Sent: Friday, December 14, 2007 3:55 PM
To: sqlite-users-CzDROfG0BjIdnm+***@public.gmane.org
Subject: Re: [sqlite] DeviceSQL

... is it not
directly comparable to DeviceSQL unless the external compiler handles
not only SQL but also PL/SQL. The addition of the command language
allows for creating a library of data manipulation functions rather than
just embedded SQL. ...



John,

I'm not sure I see added value in incorporating procedural SQL in an
embedded database like SQLite or DeviceSQL. Isn't the easily extensible
mechanism that SQLite has for creating custom functions in the host language
(C, C#, ActionScript, whatever) a fully valid replacement for whatever
procedure language could be provided through VDBE? Also doesn't the fact
that SQLite (and any embedded db) runs in-process negate the importance of
SQL procedural code? In my experience, stored procedures are usually used
to offload more work to the DB server and thus perform DB intensive code
closer to where the DB data is, which is not necessary when the DB is
already in-process?

After moving from MSSQL to SQLite for our application, which previously used
stored procedures, we've never missed the functionality of TSQL and found
creating UDFs in C# for SQLite much easier and more powerful that using TSQL
UDFs, especially 'cause they run in-process and thus have full access to the
host application's objects and code.

Sam


-------------------------------------------
We're Hiring! Seeking a passionate developer to join our team building Flex
based products. Position is in the Washington D.C. metro area. If interested
contact careers-b4xFXuYVD/yiub/***@public.gmane.org



-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[John Stanton]

Post by RB Smissaert
-----Original Message-----
Sent: Friday, December 14, 2007 3:55 PM
Subject: Re: [sqlite] DeviceSQL
... is it not
directly comparable to DeviceSQL unless the external compiler handles
not only SQL but also PL/SQL. The addition of the command language
allows for creating a library of data manipulation functions rather than
just embedded SQL. ...
John,
I'm not sure I see added value in incorporating procedural SQL in an
embedded database like SQLite or DeviceSQL. Isn't the easily extensible
mechanism that SQLite has for creating custom functions in the host language
(C, C#, ActionScript, whatever) a fully valid replacement for whatever
procedure language could be provided through VDBE? Also doesn't the fact
that SQLite (and any embedded db) runs in-process negate the importance of
SQL procedural code? In my experience, stored procedures are usually used
to offload more work to the DB server and thus perform DB intensive code
closer to where the DB data is, which is not necessary when the DB is
already in-process?
After moving from MSSQL to SQLite for our application, which previously used
stored procedures, we've never missed the functionality of TSQL and found
creating UDFs in C# for SQLite much easier and more powerful that using TSQL
UDFs, especially 'cause they run in-process and thus have full access to the
host application's objects and code.
Sam

The difference is if you are pursuing the DeviceSQL approach and
compiling a library of data manipulation functions. The partitioning is
cleaner if procedural logic can be included in those functions.

In our Sqlite applications we have implemented Javascript as a DB
procedural language by adding an Sqlite class. You can store it in the
DB and execute it. You can also run Javascript scripts which manipulate
an Sqlite DB. When using Sqlite we see the value of a DB procedural
language in the dynamic storage of rules rather than having rules
chiselled in stone in the application code. Multiple rules in
Javascript can be integrated and compiled into one executable procedure,
giving great flexibility in building systems in the "expert" style.

We chose Javascript for practical reasons. It is universally used in
WWW pages so the developers do not have any new language to learn.

Post by RB Smissaert
-------------------------------------------
We're Hiring! Seeking a passionate developer to join our team building Flex
based products. Position is in the Washington D.C. metro area. If interested
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Nicolas Williams]

Post by John Stanton

Post by Samuel R. Neff
I'm not sure I see added value in incorporating procedural SQL in an
embedded database like SQLite or DeviceSQL. Isn't the easily extensible
mechanism that SQLite has for creating custom functions in the host
language [...]

The difference is if you are pursuing the DeviceSQL approach and
compiling a library of data manipulation functions. The partitioning is
cleaner if procedural logic can be included in those functions.
In our Sqlite applications we have implemented Javascript as a DB
procedural language by adding an Sqlite class. You can store it in the
DB and execute it. You can also run Javascript scripts which manipulate
an Sqlite DB. When using Sqlite we see the value of a DB procedural
language in the dynamic storage of rules rather than having rules
chiselled in stone in the application code. Multiple rules in
Javascript can be integrated and compiled into one executable procedure,
giving great flexibility in building systems in the "expert" style.
We chose Javascript for practical reasons. It is universally used in
WWW pages so the developers do not have any new language to learn.

SQL is very expressive, and procedural SQL is too. Much more so that C.
So if you're writing an embedded app in C then procedural SQL might come
in handy (also, the VDBE code will probably be smaller than the
corresponding object code).

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Clay Dowling]

I have to say, this discussion has been very informative, although
probably not in a way that would make mr Weick happy. I've certainly
learned a lot about encirq that tells me what I need to know about doing
business with them.

Clay

Post by steveweick
Good idea... I'll pass it along to the right folks. Meanwhile, if anyone has
further questions or comments, please feel free to write me here (if they
Steve
I would like to recommend that Encriq create a forum or mailing list of
their own for those who are interesting in learning more. For me, what
might be an interesting product is quickly being overshadowed by this
thread.
--
http://www.nabble.com/DeviceSQL-tp14297970p14329799.html
Sent from the SQLite mailing list archive at Nabble.com.
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------

[Steven Fisher]

Post by Clay Dowling
I have to say, this discussion has been very informative, although
probably not in a way that would make mr Weick happy. I've certainly
learned a lot about encirq that tells me what I need to know about doing
business with them.

Same thought here. Kudos to D. Richard Hipp for keeping his cool under
provocation.

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[James Steward]

Post by steveweick
Do you need to read the code to verify reliability as your next few
sentences seems to imply? For that to be true, the reader would have to be
able to spot bugs through inspection. While that is certainly one way to
spot bugs, I seriously doubt that any shop would rely on code inspection,
when millions of dollars of potential recall costs are on the line.

I think many would agree that code inspections do find (serious) bugs,
that may not show up from testing. I'm sure your company conducts code
inspection meetings as a part of all code development. We (the company
I work for) certainly do. I know I've seen change logs that read
something like "Fixed possible buffer overflow in foo..." for open
source projects here and there as well.

Post by steveweick
In fact the SQLite marketing does not rely on code inspection as its
argument for why the code is reliable. Check it out.

That would be bad if they did, I agree. But all the testing in the
world won't uncover all the bugs either, in a complex piece of code.
See http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf .
"The Ptolemy II system itself began to be widely used, and every use of
the system exercised this
code. No problems were observed until the code deadlocked on April 26,
2004, four years later." And that was after code inspections,
regression tests and belt and braces programming techniques!

Post by steveweick
All of that said, I do admire the elegance of the SQLite code. It makes
entertaining reading. Unfortunately elegance does not translate into
performance or reliability.

Not necessarily, but it often does, and can make for better
maintainability too. I've not trawled through to SQLite code myself, so
couldn't comment. But it does have quite a few big name users, and an
active and helpful user forum, which gives me good vibes at least.

Cheerio,
James.

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Giuliano]

Hello,

is it possible (how?) to insert into 2 different fields (date) the following
values:

09:30:00 (only a time value...)
14/07/07 (only year value, 14th of december 2007)

sorry, I am not be able at all to do that. Many thanks in advance for
helping,

Giuliano


-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Ion Silvestru]

Post by Giuliano
is it possible (how?) to insert into 2 different fields (date) the following
09:30:00 (only a time value...)
14/07/07 (only year value, 14th of december 2007)

Just store date and/or time as string: "20070714" or "070714",
"093000". It is compact, you can sort them easily etc. You can store
them also as Integer: 20070714, 93000, this will save space in
database, as integers are stored in variable-length format (VarInt).


-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Giuliano]

Thanks a lot!
any suggestion for a query then that read and compare dates, for ex.:

SELECT somefiled FROM sometable WHERE datefield1 BETWEEN ' '? AND ' '?

How can I query then the string values as date?

Thanks again

Giuliano


----- Original Message -----
From: "Ion Silvestru" <silvestru-***@public.gmane.org>
To: "Giuliano" <sqlite-users-CzDROfG0BjIdnm+***@public.gmane.org>
Sent: Friday, December 14, 2007 8:55 AM
Subject: Re: [sqlite] Problems Insert with Date and Time values

Post by Ion Silvestru

Post by Giuliano
is it possible (how?) to insert into 2 different fields (date) the following
09:30:00 (only a time value...)
14/07/07 (only year value, 14th of december 2007)

Just store date and/or time as string: "20070714" or "070714",
"093000". It is compact, you can sort them easily etc. You can store
them also as Integer: 20070714, 93000, this will save space in
database, as integers are stored in variable-length format (VarInt).
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Ion Silvestru]

I avoided "BETWEEN" because this operator is treated differently in
different databases, and I don't tested how it is treated in SQLite.

http://www.w3schools.com/sql/sql_between.asp


-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Ion Silvestru]

It seems that "BETWEEN" in SQLite is treated as "BETWEEN..AND selects
fields that are between and including the test values", so it can be
used instead of ">=" and "<=".


-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Ion Silvestru]

Post by Ion Silvestru
It seems that "BETWEEN" in SQLite is treated as "BETWEEN..AND selects
fields that are between and including the test values", so it can be
used instead of ">=" and "<=".

I am sorry, but it seems I am partially correct.
I tested again and concluded:

1. "BETWEEN" in SQLite is treated as "BETWEEN..AND selects
fields that are between and including the test values",
so it can be used instead of ">=" and "<=",
ONLY if you specify COMPLETE test values, example "20071001" AND
"20071131".

2. If you specify PARTIAL test values, example "200710" AND "200711",
then "BETWEEN" in SQLite is treated as "BETWEEN..AND selects
fields between the test values, including the first test value and
excluding the last test value".

3. It is not reliable to use "BETWEEN" for now (and not only in
SQLite, but also in other DBMS), better use >= and <=.




-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[Giuliano]

Thank you again for all you work..

Giuliano

----- Original Message -----
From: "Ion Silvestru" <silvestru-***@public.gmane.org>
To: "Giuliano" <sqlite-users-CzDROfG0BjIdnm+***@public.gmane.org>
Sent: Friday, December 14, 2007 10:08 AM
Subject: Re[2]: [sqlite] Problems Insert with Date and Time values

Post by Ion Silvestru
It seems that "BETWEEN" in SQLite is treated as "BETWEEN..AND selects
fields that are between and including the test values", so it can be
used instead of ">=" and "<=".

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[John Stanton]

Testing only finds bugs, it does not guarantee accuracy. Careful design
however can establish accuracy, and to verify that methodology requires
examination of the source code.

Post by James Steward

Post by steveweick
Do you need to read the code to verify reliability as your next few
sentences seems to imply? For that to be true, the reader would have to be
able to spot bugs through inspection. While that is certainly one way to
spot bugs, I seriously doubt that any shop would rely on code inspection,
when millions of dollars of potential recall costs are on the line.

I think many would agree that code inspections do find (serious) bugs,
that may not show up from testing. I'm sure your company conducts code
inspection meetings as a part of all code development. We (the company
I work for) certainly do. I know I've seen change logs that read
something like "Fixed possible buffer overflow in foo..." for open
source projects here and there as well.

Post by steveweick
In fact the SQLite marketing does not rely on code inspection as its
argument for why the code is reliable. Check it out.

That would be bad if they did, I agree. But all the testing in the
world won't uncover all the bugs either, in a complex piece of code.
See http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf .
"The Ptolemy II system itself began to be widely used, and every use of
the system exercised this
code. No problems were observed until the code deadlocked on April 26,
2004, four years later." And that was after code inspections,
regression tests and belt and braces programming techniques!

Post by steveweick
All of that said, I do admire the elegance of the SQLite code. It makes
entertaining reading. Unfortunately elegance does not translate into
performance or reliability.

Not necessarily, but it often does, and can make for better
maintainability too. I've not trawled through to SQLite code myself, so
couldn't comment. But it does have quite a few big name users, and an
active and helpful user forum, which gives me good vibes at least.
Cheerio,
James.
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[RB Smissaert]

Couldn't find anywhere how much this costs.
Newsgroup search shows nil.
Has anybody downloaded and tried the demo?

RBS

-----Original Message-----
From: Joe Wilson [mailto:developir-/***@public.gmane.org]
Sent: 12 December 2007 17:10
To: sqlite-users-CzDROfG0BjIdnm+***@public.gmane.org
Subject: Re: [sqlite] DeviceSQL

Be careful about speculative comments.

For all anyone knows, said product could use SQLite internally with
a couple of proprietary optimizations here and there that may make it
faster in specific cases.

The sqlite public domain license would allow that sort of thing.



____________________________________________________________________________
________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

----------------------------------------------------------------------------
-
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
----------------------------------------------------------------------------
-




-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe-CzDROfG0BjIdnm+***@public.gmane.org
-----------------------------------------------------------------------------

[A. Pagaltzis]

In general claims of "20x" or even "5x" imply either serious
deficiencies in the compared product or a generous dose of
snake oil in the challenger.

Depends. The outline given by Dr. Hipp about the product’s
features may the claim quite plausible, because you pay a hefty
cut in features and reliability in exchange for a very large
increase in speed; a price that many may well find unacceptable.
(It is, after all, easy, as they say, to compute the wrong answer
in constant time.)

Regards,

[steveweick]

As shown another thread, Richard has his facts wrong. See
http://www.nabble.com/Improving-performance-of-SQLite.-Anyone-heard-of-DeviceSQL--to14280006.html#a14317195

Steve

Post by A. Pagaltzis

In general claims of "20x" or even "5x" imply either serious
deficiencies in the compared product or a generous dose of
snake oil in the challenger.

Depends. The outline given by Dr. Hipp about the product’s
features may the claim quite plausible, because you pay a hefty
cut in features and reliability in exchange for a very large
increase in speed; a price that many may well find unacceptable.
(It is, after all, easy, as they say, to compute the wrong answer
in constant time.)
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------

[steveweick]

I hope this is not a double post, but this was answered in another thread.
See
http://www.nabble.com/Improving-performance-of-SQLite.-Anyone-heard-of-DeviceSQL--to14280006.html#a14317195

Post by d***@public.gmane.org

Post by John Stanton
I received an email promoting a DeviceSQL web presentation. It
specifically targets Sqlite and promises 5X performance.

If you view their web presentation and/or try out Encirq's
products, I would be very interested to hear your impressions.
Even better would be if you could blog about it.
Encirq has for years been running Google Adsense ads claiming
to be 20x faster than SQLite. (Dunno why they have now reduced
that claim to 5x faster.) But I have never yet seen an
independent confirmation of this. Nor even have I been able
to find anybody who is actually using DeviceSQL in a product.
Web searches turn up nothing but marketing literature coming
directly or indirectly from Encirq. Some independent analysis
(regardless of whether it is favorable or unfavorable to SQLite)
would be appreciated.
* It is NOT transactional. There is no such thing as ROLLBACK.
* If you lose power during a write, your database is toast.
* If your database schema changes, you have to recompile
your application.
* The database file format changes depending on the schema.
* DeviceSQL is not a general-purpose database engine. You
compile SQL statements into C code on a development
workstation, then compile the C code for your embedded
device.
I can imagine circumstances where the DeviceSQL approach,
while much less flexible and forgiving than SQLite, might
be a better way to go, depending on what you are trying to
do. But I have not gotten good vibes from Encirq as a
company. And I have no idea how reliable the DeviceSQL
product is. I would really appreciate your thoughts on
that subject.
--
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------