On Fri, Dec 14, 2007 at 04:28:07PM -0600, John Stanton wrote:
> Samuel R. Neff wrote:
> >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
Samuel R. Neff wrote:
-Original Message-
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Friday, December 14, 2007 3:55 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] DeviceSQL
... is it not
directly comparable to DeviceSQL unless the external compiler handles
not only SQL
-Original Message-
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Friday, December 14, 2007 3:55 PM
To: sqlite-users@sqlite.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
users@sqlite.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
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 compile
On 14-Dec-2007, at 5:41 AM, Clay Dowling wrote:
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
[EMAIL PROTECTED] wrote:
Dennis Cote <[EMAIL PROTECTED]> wrote:
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
"Noah Hart" <[EMAIL PROTECTED]> wrote:
> 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 ofte
On Fri, Dec 14, 2007 at 04:20:15PM +, [EMAIL PROTECTED] wrote:
> 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 thr
Why can't new OP codes be simply added to the end, so that the
serializations will always work?
Noah
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, December 14, 2007 8:20 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] DeviceSQL
Importance:
Nicolas Williams <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 14, 2007 at 03:38:17PM +, [EMAIL PROTECTED] wrote:
> > That would be the Serialized Statement Extension, SSE.
> > The SSE provides the programmer with two new APIs:
>
> Would it be useful to generate human-readable VDBE "assemply"?
>
>
On Fri, Dec 14, 2007 at 10:10:04AM -0600, Nicolas Williams wrote:
> On Fri, Dec 14, 2007 at 03:38:17PM +, [EMAIL PROTECTED] wrote:
> > That would be the Serialized Statement Extension, SSE.
> > The SSE provides the programmer with two new APIs:
>
> Would it be useful to generate human-readable
On Fri, Dec 14, 2007 at 03:38:17PM +, [EMAIL PROTECTED] wrote:
> That would be the Serialized Statement Extension, SSE.
> The SSE provides the programmer with two new APIs:
Would it be useful to generate human-readable VDBE "assemply"?
Or, how do you develop parser changes that involve new VD
Dennis Cote <[EMAIL PROTECTED]> wrote:
>
> 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 W
On Dec 14, 2007 10:38 AM, <[EMAIL PROTECTED]> wrote:
> 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
Dennis Cote <[EMAIL PROTECTED]> wrote:
>
> > 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
John Stanton wrote:
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 applic
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
steveweick wrote:
>
> Good idea... I'll pass it along to the
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
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
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 no
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 [EMAIL PROTECTED]
Steve
I would like to recommend that Encriq create a forum or mailing list of
thei
I concur. Quite an interesting marketing strategy; Join you competitors'
mailing lists and trash talk them. LOL
-Original Message-
From: dcharno [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 13, 2007 8:30 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] DeviceSQL
I would
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
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 s
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.
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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> [2007-12-12 17:55]:
>> In general claims of "20x" or even "5x"
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 <[EMAIL PROTECTED]> wrote:
>> I received an email promoting a Dev
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:[EMAIL PROTECTED]
Sent: 12 December 2007 17:10
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] DeviceSQL
Be careful
Joe Wilson <[EMAIL PROTECTED]> 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 a
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.
__
[EMAIL PROTECTED] wrote:
John Stanton <[EMAIL PROTECTED]> 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 yo
John Stanton <[EMAIL PROTECTED]> 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 be
34 matches
Mail list logo