A recent check-in to the SQLite master code broke my encryption codec. Can
anyone explain the purpose of Dan Kennedy's checkin of Jan 9, 2016 with
comment
*"If a single page is written to the wal file more than once, have each
subsequent copy overwrite the original frame."*
Is this an
On 21 January 2016 at 11:16, Richard Hipp wrote:
> The change that is causing your problem was put in at the suggestion
> of Hanno B?ck on the sqlite-dev mailing list. Hanno said he was going
> to try to contact you off-list in order to figure out how to reproduce
> the issue you are seeing and
On 22 January 2016 at 14:24, Simon Slavin wrote:
>
> On 22 Jan 2016, at 4:01am, Rowan Worth wrote:
>
> > To a point I agree, but in reality there's a fixed amount of work
> involved
> > with each write transaction. I recently profiled an operation involving
> > ~75,000 rows that took ~8.5
On Fri, 22 Jan 2016 06:24:08 +
Simon Slavin wrote:
>
> On 22 Jan 2016, at 4:01am, Rowan Worth wrote:
>
> > To a point I agree, but in reality there's a fixed amount of work
> > involved with each write transaction. I recently profiled an
> > operation involving ~75,000 rows that took ~8.5
On Thu, 21 Jan 2016 22:21:31 +0530
Deepak wrote:
> How can improve the service performance here? Keeping in mind,
>
>
>- There will be no new inserts (ignoring addition of few hundred
> URLs once a day while overwriting the older ones). Size of the DB
> will be more or less constant in
On Fri, Jan 22, 2016 at 1:29 PM, Richard Hipp wrote:
> The (partial) index is also useless for sorting:
>
> SELECT * FROM t1 ORDER BY x;
>
Is that a fundamental thing though? Or a pragmatic implementation decision?
Nulls come before or after non-null, no? So couldn't the sort work like
On Fri, Jan 22, 2016 at 12:22 PM, Stephan Beal
wrote:
>
>
> On Fri, Jan 22, 2016 at 12:11 PM, Bart Smissaert > wrote:
>
>> Say I want 1 random numbers between 100 and 1000 how can I do that
>> without
>> selecting from a table?
>> I know I can do:
>> select abs(random() %(1000 - 100)) + 100
Hey everyone
I'm looking for various math/aggregation/stats functions for SQLite past
what's offered by the existing language
Deciles, linear math (correlation, regression), ranking, etc
I've seen this
http://www.sqlite.org/contrib/download/extension-functions.c?get=25 buts
it's not nearly
You can either printf() the statement to insert the value into the text, or use
SQL variables to prepare the generic statement and sqlite3_bind_xxx() the
desired value.
-Urspr?ngliche Nachricht-
Von: sqlite-users-bounces at mailinglists.sqlite.org
[mailto:sqlite-users-bounces at
On 21 Jan 2016, at 6:04pm, Krishnajith S S wrote:
> How can I store the data from a variable into a field in the database
> table?
What programming language are you writing in ?
Simon.
Thanks, will look at that as well.
I was thinking achieving this with a user function,
maybe using sqlite3_randomness, but I this looks very good.
RBS
On Fri, Jan 22, 2016 at 12:39 PM, Stephan Beal
wrote:
> On Fri, Jan 22, 2016 at 12:22 PM, Stephan Beal
> wrote:
>
> >
> >
> > On Fri, Jan 22,
Thanks, that works very well and is a lot faster than involving a table.
I don't need the x output, so I have done:
with conf(max) as
(select 1), rnd(n, x) as
(select abs(random() %(1000 - 100)) + 100, 1 union all
select abs(random() %(1000 - 100)) + 100, x + 1
from rnd where x < (select max
On Jan 22, 2016, at 11:54 AM, James K. Lowden
wrote:
>
> On Fri, 22 Jan 2016 06:24:08 +
> Simon Slavin wrote:
>
>> This is, of course, all about waiting for a rotating disc to be in
>> the right place.
>
> All true, but I think you're exaggerating if you're implying that's
> what the
On Fri, Jan 22, 2016 at 12:11 PM, Bart Smissaert
wrote:
> Say I want 1 random numbers between 100 and 1000 how can I do that
> without
> selecting from a table?
> I know I can do:
> select abs(random() %(1000 - 100)) + 100 as rnd from TableWith1Rows
> but there must be a better way.
>
>
On 22 January 2016 at 06:33, Warren Young wrote:
> With SQLite?s lack of row-level locking, your usage pattern should distill
> to ?get in, get done, and get out, ASAP.? Many fine-grained queries are
> better than heroic multi-statement queries that change the world.
>
To a point I agree, but
> Shutting down power right after a successfully committed
> transaction rolls back that transaction on next startup.
nitpick: This is sqlite behaving as advertised. See
https://www.sqlite.org/lockingv3.html section 5.0 step 6, and
https://www.sqlite.org/atomiccommit.html section 3.11 which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/01/16 20:11, Roger Binns wrote:
> SQLite 3.10 changed the xCurrentTime (note not -64 version) method
> for From the documentation it is hard to tell who is at "fault"
> here. xCurrentTime is documented as optional now, but was it when I
> first
On Jan 22, 2016, at 6:15 AM, Hick Gunter wrote:
>
> You can either printf() the statement to insert the value into the text
Please don?t say such things to newbies. It?s fine for an integer, but he?s
going to move on to strings next and then he?ll have a SQL injection
vulnerability.
Say I want 1 random numbers between 100 and 1000 how can I do that
without
selecting from a table?
I know I can do:
select abs(random() %(1000 - 100)) + 100 as rnd from TableWith1Rows
but there must be a better way.
RBS
On Jan 21, 2016, at 9:01 PM, Rowan Worth wrote:
>
> On 22 January 2016 at 06:33, Warren Young wrote:
>
>> get in, get done, and get out, ASAP.
>
> To a point I agree, but in reality there's a fixed amount of work involved
> with each write transaction. I recently profiled an operation
Denis Burke wrote:
> Your suggestion to make it a partial index makes sense. When would
> you NOT want to add the "where [indexedColumn] IS NOT NULL"? Seems
> like it would always be helpful.
If the database cannot prove that a query will never search for a NULL
value, it cannot use that index.
On 1/21/16, Denis Burke wrote:
> When
> would you NOT want to add the "where [indexedColumn] IS NOT NULL"? Seems
> like it would always be helpful.
>
CREATE TABLE t1(x);
CREATE INDEX t1x ON t1(x) WHERE x IS NOT NULL;
That index will not work on queries like this (obviously):
SELECT *
On 22 Jan 2016, at 4:01am, Rowan Worth wrote:
> To a point I agree, but in reality there's a fixed amount of work involved
> with each write transaction. I recently profiled an operation involving
> ~75,000 rows that took ~8.5 minutes to complete, and found that 80% of the
> time was spent
23 matches
Mail list logo
