Re: [sqlite] Sampling Data

> > I'm using some pseudo code here, I hope this make sense. > > Example Table: > tableID > Minute > Watt > > I'm trying to sum average the watt column by minute. > > Thanks in advance. > > > -- Regards, Rod Dav4is / P.O. Box 118 / Hyde Park, NY 12538 / US

Re: [sqlite] Moving Average?

ot;over" statement part to register. > > Any ideas? > > Thanks! > -- Regards, Rod Dav4is / P.O. Box 118 / Hyde Park, NY 12538 / USA Genealogy, et Cetera: http://freepages.rootsweb.ancestry.com/~dav4is/ 538 ancestral & collateral families, mostly 17°-19° century

Re: [sqlite] How long should Insert take?

Well, That certainly did the trick. Much obliged! Rate now > 2000 inserts/second including transaction processing and 3390 inserts. -R. Igor Tandetnik wrote: > Rod Dav4is <dav...@yahoo.com> wrote: > >> *Insert rate*: 7/sec. >> > > Run batches of inserts

Re: [sqlite] How long should Insert take?

Thanks. I'll give it a try. Igor Tandetnik wrote: > Rod Dav4is <dav...@yahoo.com> wrote: > >> *Insert rate*: 7/sec. >> > > Run batches of inserts within a single transaction. It's not the insert > itself that's slow, it's the process of committing

[sqlite] How long should Insert take?

seems rather slow to me. I expected something perhaps an order of magnitude faster. The time is not spent in the Rexx overhead. Commenting out the SQL Insert statement the loop runs in an eyeblink. Am I expecting too much? I think that SQLite2 did this much faster. -R. -- Regards, Rod Dav4

Re: [sqlite] Problems encountered on upgrade from SQLite2 to -3

; or code? > > > Please, make us the favor to switch to Oracle or any other utterly > expensive RDBMS and go whine elsewhere for lack of support/reactivity > (esp. Oracle). > > > > > ___ > sqlite-users mailing list > sq

Re: [sqlite] Problems encountered on upgrade from SQLite2 to -3

t; means that conversion is made in any case i.e. > if text doesn't contain number it will be converted to 0. > > Pavel > > -- Regards, Rod Dav4is / P.O. Box 118 / Hyde Park, NY 12538 / USA Genealogy, et Cetera: http://freepages.rootsweb.ancestry.com/~dav4is/ 538 ancestral &am

Re: [sqlite] Problems encountered on upgrade from SQLite2 to -3

d to the value of expression B before the comparison takes place. (Reading "conversion is applied" for "affinity is applied".) -R. -- Regards, Rod Dav4is / P.O. Box 118 / Hyde Park, NY 12538 / USA Genealogy, et Cetera: http://freepages.rootsweb.ancestry.com/~dav4is/ 538

Re: [sqlite] Problems encountered on upgrade from SQLite2 to -3

tml. > Yes, that is where I looked to find what "applied affinity" meant, but never found a crisp definition. If it means "converted to", it should say that. > > Pavel > > On Thu, Sep 3, 2009 at 6:31 AM, Rod Dav4is<dav...@yahoo.com> wrote: > >> 1. *re

Re: [sqlite] Problems encountered on upgrade from SQLite2 to -3

oving single quotes from literals, in order for selects to have the same result as on version 2. Perhaps the fact that my column definitions declared no typing has an effect here? -R. -- Regards, Rod Dav4is / P.O. Box 118 / Hyde Park, NY 12538 / USA Genealogy, et Cetera: http://freepage

Re: [sqlite] Problems encountered on upgrade from SQLite2 to -3

ith a value of unquoted 1. (Columns were defined with no type.) The v3 document (in discussing conversions) uses the expression "affinity is applied" without defining what that means. Does it mean "conversion to"? -R. D. Richard Hipp wrote: > On Sep 1, 2009,

Re: [sqlite] Problems encountered on upgrade from SQLite2 to -3

Thanks for reminding me: A thing's value is generally proportional to its cost. And the attitude of its support team figures in there, too. -R. P Kishor wrote: > On Wed, Sep 2, 2009 at 3:54 PM, Rod Dav4is<dav...@yahoo.com> wrote: > >> Whether _you_ consider them problems

Re: [sqlite] Problems encountered on upgrade from SQLite2 to -3

wrote: > On Sep 1, 2009, at 4:38 PM, Rod Dav4is wrote: > > >> Aren't these problems considered worth fixing ? >> > > I do not consider them to be problems. > > >> Rod Dav4is wrote: >> >>> 1. *OID vs ROWID*: Specificatio

Re: [sqlite] Problems encountered on upgrade from SQLite2 to -3

Aren't these problems considered worth fixing ? Rod Dav4is wrote: >1. *OID vs ROWID*: Specification of the OID field name (in SELECT) > did not set Rexx variables X.OID.n, but instead set variables > x.ROWID.n >2. *Quotes in SELECT*: Specification of Field='3' fa

[sqlite] Problems encountered on upgrade from SQLite2 to -3

1. *OID vs ROWID*: Specification of the OID field name (in SELECT) did not set Rexx variables X.OID.n, but instead set variables x.ROWID.n 2. *Quotes in SELECT*: Specification of Field='3' failed to find hits; Field=3 (i.e. without quotes) was required. -- Regards, Rod

[sqlite] A problem with versions of SQLite

to the current 3.6. Perhaps the version 3.6 db manager will automatically convert my 2.1 to the new 3.6 format (or is that too much to hope for?). All help and advice welcomed! -R. -- Regards, Rod Dav4is / P.O. Box 118 / Hyde Park, NY 12538 / USA Genealogy, et Cetera: http

Re: [sqlite] Unusual use of the LIKE operator (long)

Very nice: Identify a date format. *Anybody else? *-R.* * Andrew Finkenstadt wrote in part: 8>< and we select the date_format column based on the likeness of the date_pattern column, run it through to_date, catch any exceptions, and return the DATE column. --a

Re: [sqlite] Unusual use of the LIKE operator (long)

work? -R. Andrew Finkenstadt wrote: We've used this exact technique in a table called "ANY_DATE_FORMAT" since 1997... admittedly in Oracle, but the principle still applies. It's great for coalescing the number of states necessary to implement parsers. :) --andy On 8/18/07, Rod Dav4

[sqlite] Unusual use of the LIKE operator (long)

ake those tests, but the operation using SQL is simple to implement. _*Finite State Machine*_ The state transition tuples are represented in SQL, again with don't care positions coded as LIKE wildcards. -- Regards, Rod Dav4is / P.O. Box 118 / Hyde Park, NY 12538 / USA Genealogy, et Cetera: ht

Re: [sqlite] like-op

that it would also find records where the 4th word was '1', but that will not be possible in my situation. -R. David Morel wrote: Le mer 15/09/2004 à 00:43, Peter a écrit : Rod Dav4is wrote: 'm reminded of the guy who wanted to buy a loaf of bread and was told how to build a bakery. ;O) Don't

Re: [sqlite] like-op

) So, I guess the bottom line answer is No. -R. D. Richard Hipp wrote: Rod Dav4is wrote: Have you given any thought to adding a GREP option to the like-ops? I have a situation where I'd like to select records based on the value of the 3rd word in a particular column. Unless there's a way to do

[sqlite] like-op

Have you given any thought to adding a GREP option to the like-ops? I have a situation where I'd like to select records based on the value of the 3rd word in a particular column. Unless there's a way to do it with LIKE or GLOB? -- Regards, Rod Dav4is / P.O. Box 118 / Hyde Park, NY 12538

[sqlite] TEST

Is this how I should send messages to the list? Your %^&@# verbose instructions tell everything but how to do that! -- Regards, Rod Dav4is / P.O. Box 118 / Hyde Park, NY 12538 / USA Genealogy, et Cetera: http://freepages.rootsweb.com/~dav4is/ 391 ancestral & collateral families, mos