DeviceSQL

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

DeviceSQL

John Stanton-3
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 [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

D. Richard Hipp
John Stanton <[hidden email]> wrote:
> 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 <[hidden email]>


-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

John Stanton-3
[hidden email] wrote:

> John Stanton <[hidden email]> wrote:
>> 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 <[hidden email]>
>
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 [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

developir@yahoo.com
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 [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

D. Richard Hipp
Joe Wilson <[hidden email]> wrote:
> 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 <[hidden email]>


-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

RE: DeviceSQL

RB Smissaert
In reply to this post by developir@yahoo.com
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:[hidden email]]
Sent: 12 December 2007 17:10
To: [hidden email]
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 [hidden email]
----------------------------------------------------------------------------
-




-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

Aristotle Pagaltzis
In reply to this post by John Stanton-3
* John Stanton <[hidden email]> [2007-12-12 17:55]:
> 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/>

-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

steveweick
In reply to this post by D. Richard Hipp
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


D. Richard Hipp wrote
John Stanton <johns@viacognis.com> wrote:
> 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 <drh@hwaci.com>


-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe@sqlite.org
-----------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

steveweick
In reply to this post by Aristotle Pagaltzis
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
A. Pagaltzis wrote
* John Stanton <johns@viacognis.com> [2007-12-12 17:55]:
> 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/>

-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe@sqlite.org
-----------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

steveweick
In reply to this post by D. Richard Hipp
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


D. Richard Hipp wrote
Joe Wilson <developir@yahoo.com> wrote:
> 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 <drh@hwaci.com>


-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe@sqlite.org
-----------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

James Steward-2
steveweick wrote:
> 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 [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

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
James Steward-2 wrote
steveweick wrote:
> 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@sqlite.org
-----------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

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.


>
> 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
>
> James Steward-2 wrote:
>> steveweick wrote:
>>> 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 [hidden email]
>> -----------------------------------------------------------------------------
>>
>>
>>
>


-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

RE: DeviceSQL

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

-----Original Message-----
From: dcharno [mailto:[hidden email]]
Sent: Thursday, December 13, 2007 8:30 PM
To: [hidden email]
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.


>
> 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
>
> James Steward-2 wrote:
>> steveweick wrote:
>>> 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 [hidden email]
>>
------------------------------------------------------------------------
-----
>>
>>
>>
>


------------------------------------------------------------------------
-----
To unsubscribe, send email to [hidden email]
------------------------------------------------------------------------
-----


-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

steveweick
In reply to this post by dcharno
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@encirq.com.

Steve
<quote author="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.

Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

John Stanton-3
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.

steveweick wrote:

> 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 [hidden email].
>
> 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 [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

steveweick
Hi John,

Sorry you couldn't attend.  I'm sure you would have found it useful. Interestingly enough there was another John Stanton there in your place.  I'm not going to guess how that happened :-)

In the session we explained that Encirq's product supports 3 (count'em) styles of interface: the compiled interface that you mention below, a C callable interface, and an interpreted interface.  The benchmark effort compared the first and the last of those (our fastest and slowest, respectively) with what we believe to be SQLite's fastest (prepare/execute) style interface. Also as we mentioned in the webinar, we would be happy to supply you with the code that was used to measure SQLite and DeviceSQL.  Your call, of course.

I think your comments about general purpose vs. special purpose are probably on target, if I understand where you are headed. SQLite implements some SQL language features that just aren't used in typical devices. (It also implements nulls which were just a problem created by some SQL early misdirection... a subject for the information theorists among us and boring for the rest). We would have to talk about specifics to see how aligned we are on this point.

Thanks, I guess, for the comment on my resume.  I am no fan of our stealth marketing.  I just handle the technical side of the business.  But I will be more than happy to pass your comment along.

Regards,

Steve


John Stanton-3 wrote
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.

steveweick wrote:
> 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@encirq.com.
>
> 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@sqlite.org
-----------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

James Steward-2
In reply to this post by steveweick
steveweick wrote:
> 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.

> 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!
> 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 [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Problems Insert with Date and Time values

Runnerpizza Net
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 [hidden email]
-----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: DeviceSQL

John Stanton-3
In reply to this post by James Steward-2
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.

James Steward wrote:

> steveweick wrote:
>> 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.
>
>> 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!
>> 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 [hidden email]
> -----------------------------------------------------------------------------
>
>


-----------------------------------------------------------------------------
To unsubscribe, send email to [hidden email]
-----------------------------------------------------------------------------

123