Hi,
We got a report of a 'pragma integrity_check' failure on the user mailing list
for our application [1].
There was no data loss involved (just the index was corrupted), but I thought
you might want to take a look.
The database was written to by our application (SX 2.0) which uses SQLite
> > Sqlite accepts (but Postgres does not):
> > LIMIT -1 OFFSET nnn
> > LIMIT -1
> >
> > These all have the same meaning of no limit, but there is no common
> > ground in the syntax.
>
> Yes and Yes. Documented behaviour. There are some strange situations if
the
> two clauses can't both be
> > Richard Hipp seems to be on record as saying:
> > "SQLite can be thought of as a derivative of PostgreSQL. SQLite was
> > originally written from PostgreSQL 6.5 documentation, and the SQLite
> > developers still use PostgreSQL as a reference platform to verify that
> > SQLite is working
Fair enough.
On Thu, May 12, 2016 at 9:24 PM, dandl wrote:
> > > Richard Hipp seems to be on record as saying:
> > > "SQLite can be thought of as a derivative of PostgreSQL. SQLite was
> > > originally written from PostgreSQL 6.5 documentation, and the SQLite
> > > developers still use
Hi sqlite experts,
I am using sqlite back up API of the latest sqlite version. I find an issue
that the target database seems not shrink when the source shrinks.
Here are my steps:
The source database is an in-memory database
1. Open the source database and preserve the connection for
On Fri, May 13, 2016 at 8:29 AM, Yihong Zhan wrote:
> Hi sqlite experts,
>
> I am using sqlite back up API of the latest sqlite version. I find an
> issue that the target database seems not shrink when the source shrinks.
> ...
> Is it a bug, a known issue? I believe the size of the target
On 2016/05/13 5:24 AM, dandl wrote:
>>> Richard Hipp seems to be on record as saying:
>>> "SQLite can be thought of as a derivative of PostgreSQL. SQLite was
>>> originally written from PostgreSQL 6.5 documentation, and the SQLite
>>> developers still use PostgreSQL as a reference platform to
On 13 May 2016, at 3:07pm, dandl wrote:
> I have no deep knowledge of standard SQL.
I used to know SQL92 very well. There's no facility for doing anything like
LIMIT or OFFSET in it. You had to use your programming language to work your
way through all the results and skip the ones you
Hi all,
Anyone know if/how you can call the FTS5 tokeniser functions manually? e.g. I
want to look something up in the fts5vocab table but can't as I need to
split/stem the initial value first before querying the table?
To illustrate:
sqlite> CREATE VIRTUAL TABLE ft1 USING fts5(x, tokenize =
Hi Simon,
Sorry, maybe we're crossing wires, but I'm not sure to what you're referring.
How is defining the type as DATE impeding my attempt to get a value of 0 for
non-existent rows?
Ryan's response with a CTE seems to probably be what I want (not had the
opportunity to test it yet - CTE's
On 05/13/2016 09:19 PM, Matt Hamilton wrote:
> Hi all,
>Anyone know if/how you can call the FTS5 tokeniser functions manually?
> e.g. I want to look something up in the fts5vocab table but can't as I need
> to split/stem the initial value first before querying the table?
>
> To illustrate:
>
On 13 May 2016, at 3:56pm, Jonathan Moules
wrote:
> Sorry, maybe we're crossing wires, but I'm not sure to what you're
> referring. How is defining the type as DATE impeding my attempt to get a
> value of 0 for non-existent rows?
> Ryan's response with a CTE seems to probably be what I want
Imagine I have a single table containing a single text column, of user names.
I'm trying to find user names which differ only by case.
> select count(*) from os_users
1969
> select u1.user, u2.user from os_users u1, os_users u2 where upper(u1.user) =
> upper(u2.user) and u1.user <> u2.user
Dominique Devienne wrote:
> Imagine I have a single table containing a single text column, of user names.
> I'm trying to find user names which differ only by case.
>
> select u1.user, u2.user from os_users u1, os_users u2 where upper(u1.user) =
> upper(u2.user) and u1.user <> u2.user;
> select
On Fri, May 13, 2016 at 10:14 AM, Dominique Devienne
wrote:
> Imagine I have a single table containing a single text column, of user
> names.
> I'm trying to find user names which differ only by case.
>
> > select count(*) from os_users
> 1969
>
> > select u1.user, u2.user from os_users u1,
On Fri, May 13, 2016 at 5:23 PM, Clemens Ladisch wrote:
> Dominique Devienne wrote:
>> select u1.user, u2.user from os_users u1, os_users u2 where upper(u1.user)
>> = upper(u2.user) and u1.user <> u2.user;
>> [...] but they are slow (almost 3s, with close to 4M steps, i.e. O(N^2))
>
> You can
On Fri, May 13, 2016 at 5:27 PM, John McKown
wrote:
>> > select group_concat(user) from os_users group by upper(user) having
>> count(*) > 1
>> foo,FOO
>>
>
> how about: SELECT group_concat(user,"|") FROM os_users GROUP BY
> upper(user) HAVING count(*) > 1
Thanks John. Sorry, I wasn't clear.
On 5/13/2016 11:51 AM, Dominique Devienne wrote:
> But it still returns both rows. Any idea on that part?
Change "u1.user <> u2.user" to "u1.user < u2.user"
--
Igor Tandetnik
On Fri, May 13, 2016 at 6:06 PM, Igor Tandetnik wrote:
> On 5/13/2016 11:51 AM, Dominique Devienne wrote:
>> But it still returns both rows. Any idea on that part?
>
> Change "u1.user <> u2.user" to "u1.user < u2.user"
Seems obvious once someone clever shows you, yet isn't... Thanks Igor!
> On 13 May 2016, at 16:04, Dan Kennedy wrote:
>
> On 05/13/2016 09:19 PM, Matt Hamilton wrote:
>> Hi all,
>> Anyone know if/how you can call the FTS5 tokeniser functions manually? e.g.
>> I want to look something up in the fts5vocab table but can't as I need to
>> split/stem the initial
> I used to know SQL92 very well. There's no facility for doing anything
> like LIMIT or OFFSET in it. You had to use your programming language to
> work your way through all the results and skip the ones you didn't want.
>
> It is because there was no standard for this that each of the big SQL
Hi,
I have two questions/observations/suggestions related to SQLite function
"group_concat".
This function is extremely useful since it replaces in an elegant and concise
way quite tricky procedures. However, it misses two features of which I would
like to discuss the work-around.
Let's
On Fri, May 13, 2016 at 7:33 PM, wrote:
> Derby:
> SELECT * FROM schemaTableName FETCH FIRST ROW ONLY
> [...]
> Oracle:
> SELECT * FROM schemaTableName WHERE ROWNUM=1
Oracle 12c added FETCH FIRST ROW ONLY too. --DD
On 2016-05-13 7:07 AM, dandl wrote:
> I checked a copy of the
> 2003 standard and there doesn't seem to be anything similar. I don't have
> anything later.
Whitemarsh is your friend.
http://www.wiscorp.com/SQLStandards.html
They have a copy of the SQL 2011/2 draft there, under the erroneous
24 matches
Mail list logo