[sqlite] The server https://www3.sqlite.org/ is not working
Hello Richard ! Today the server https://www3.sqlite.org/ is not working, I usually follow the sqlite3 repository daily and I think that could be a good idea to add an option to fossil update command to allow override the url for the repository so in cases like today I could do: fossil updata --url https://www1.sqlite.org/cgi/src Cheers ! ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] FTS5 MATCH using "string*" matches just the exact string
Thanks for your answer Eric,Sandu About the first idea of Eric I have to say its correct for me when I do a test with another fts5 table with no huge rows but my database has that problem.And about the other possibility I tested that before to set "*"at the first and end of the match but I have got an error.Here if there is no problem I will attach an example Arabic text database if you search for 'أعلم*' it must find 83 rows but it will find 49 which is the same with "أعلم" results.and if you put "*"at the both sides you will get error.I don't know if I did something wrong during creation but this is all I have got. On Tue, Sep 11, 2018 at 10:20 AM Sandu Buraga wrote: > In Arabic you have a different direction of the text. Might be that the > reason? > > Sandu > > Eric Minbiole schrieb am Di., 11. Sep. 2018, 00:23: > > > > SELECT rowid,text > > > FROM table > > > WHERE table MATCH 'أعلم*'; > > > > > > And I have to add this that my data is Arabic text. > > > > > > This method must find words that contains 'أعلم' but it doesn't. What > > > should I do now. > > > > > > > > I just tried this in SQLite version 3.24.0 on a Mac, and it seems to > work. > > Please see my example below. In particular, the first select doesn't > have a > > *, so it doesn't find the word. The second example includes a trailing *, > > so it performs a "starts with" search, and does find the match. (Note > that > > I simply doubled the letters of your original arabic text to make a > longer > > word.) > > > > MacBook-II:Programs eric$ ./sqlite3 > > > SQLite version 3.24.0 2018-06-04 19:24:41 > > > Enter ".help" for usage hints. > > > Connected to a transient in-memory database. > > > Use ".open FILENAME" to reopen on a persistent database. > > > sqlite> CREATE VIRTUAL TABLE fts USING fts5(doc); > > > sqlite> INSERT INTO fts (rowid, doc) VALUES (1, 'english text'); > > > sqlite> INSERT INTO fts (rowid, doc) VALUES (2, 'arabic أعلمأعلم'); > > > sqlite> SELECT rowid FROM fts WHERE fts MATCH 'أعلم'; > > > sqlite> SELECT rowid FROM fts WHERE fts MATCH 'أعلم*'; > > > 2 > > > sqlite> > > > > > > > One possible explanation: You mentioned that you want a "contains" > search. > > However, the trailing asterisk in your example only results in a "begins > > with" search. If you really want a "contains" search, you'll need to put > > the * at both the beginning and end of the match word. E.g., "WHERE fts > > MATCH '*asdf*'; > > > > Hope this is helpful. > > > > ~Eric > > ___ > > sqlite-users mailing list > > sqlite-users@mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite3_column_type returns NOT SQLITE_NULL and the following sqlite3_column_text returns with nullptr
I've a prepared select statement (the database is in :memory: based.).
After binding the input values, calling next, checking the result type
of a text column, sometimes the follwing sqlite3_column_text returns
with a nullptr.
The stange thing is: the prior called sqlite3_column_type do not return
with SQLITE_NULL.
if (sqlite3_column_type(_sqlite3_stmt, Field) == SQLITE_NULL)
return false;
LPCSTR cp = (LPCSTR)sqlite3_column_text(_sqlite3_stmt, Field);
if (cp == nullptr)
{
ASSERT(false);
return false;
}
Is that correct? May it be possible that sqlite3_column_type returns NOT
SQLITE_NULL and the following sqlite3_column_text returns with nullptr?
Thx for any hint
heribert
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] [EXTERNAL] sqlite3_column_type returns NOT SQLITE_NULL and the following sqlite3_column_text returns with nullptr
You are assuming that the column is either NULL or a SQLITE_TEXT value. This
assumption is obviously violated by the real data returned by your query (which
you do not show).
A second possibility would be that another thread has done something to your
prepared statement between retrieving the column type and retrieving the data.
-Ursprüngliche Nachricht-
Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im
Auftrag von heribert
Gesendet: Dienstag, 11. September 2018 13:59
An: SQLite mailing list
Betreff: [EXTERNAL] [sqlite] sqlite3_column_type returns NOT SQLITE_NULL and
the following sqlite3_column_text returns with nullptr
I've a prepared select statement (the database is in :memory: based.).
After binding the input values, calling next, checking the result type of a
text column, sometimes the follwing sqlite3_column_text returns with a nullptr.
The stange thing is: the prior called sqlite3_column_type do not return with
SQLITE_NULL.
if (sqlite3_column_type(_sqlite3_stmt, Field) == SQLITE_NULL)
return false;
LPCSTR cp = (LPCSTR)sqlite3_column_text(_sqlite3_stmt, Field); if (cp ==
nullptr) {
ASSERT(false);
return false;
}
Is that correct? May it be possible that sqlite3_column_type returns NOT
SQLITE_NULL and the following sqlite3_column_text returns with nullptr?
Thx for any hint
heribert
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
Gunter Hick | Software Engineer | Scientific Games International GmbH |
Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43
1 80100 - 0
May be privileged. May be confidential. Please delete if not the addressee.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite3_column_type returns NOT SQLITE_NULL and the following sqlite3_column_text returns with nullptr
Thx Gunter...
that's the problem. I've capsuled the sqlite access in some database
classes. So i have only the call a function named getProperty with some
parameters.
But in some cases it may be possible that the instance of the object
calls this function from another thread (with the same stmt).
The main thread reads... meanwhile the other thread access resets the
stmt results...
Thx again!
Am 11.09.2018 um 13:58 schrieb heribert:
I've a prepared select statement (the database is in :memory: based.).
After binding the input values, calling next, checking the result type
of a text column, sometimes the follwing sqlite3_column_text returns
with a nullptr.
The stange thing is: the prior called sqlite3_column_type do not
return with SQLITE_NULL.
if (sqlite3_column_type(_sqlite3_stmt, Field) == SQLITE_NULL)
return false;
LPCSTR cp = (LPCSTR)sqlite3_column_text(_sqlite3_stmt, Field);
if (cp == nullptr)
{
ASSERT(false);
return false;
}
Is that correct? May it be possible that sqlite3_column_type returns
NOT SQLITE_NULL and the following sqlite3_column_text returns with
nullptr?
Thx for any hint
heribert
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite3_column_type returns NOT SQLITE_NULL and the following sqlite3_column_text returns with nullptr
On 9/11/18, heribert wrote: > I've a prepared select statement (the database is in :memory: based.). > After binding the input values, calling next, checking the result type > of a text column, sometimes the follwing sqlite3_column_text returns > with a nullptr. > > The stange thing is: the prior called sqlite3_column_type do not return > with SQLITE_NULL. That can happen when SQLite needs to do a type conversion (INTEGER to TEXT, or UTF-16 to UTF-8, for example) and it is unable to allocate sufficient memory to carry out the conversion. How big is your text string? -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] FTS5 MATCH using "string*" matches just the exact string
On 09/11/2018 01:26 PM, Maziar Parsijani wrote: Thanks for your answer Eric,Sandu About the first idea of Eric I have to say its correct for me when I do a test with another fts5 table with no huge rows but my database has that problem.And about the other possibility I tested that before to set "*"at the first and end of the match but I have got an error.Here if there is no problem I will attach an example Arabic text database if you search for 'أعلم*' it must find 83 rows but it will find 49 which is the same with "أعلم" results.and if you put "*"at the both sides you will get error.I don't know if I did something wrong during creation but this is all I have got. The "*" may only occur following a string in an fts5 expression, not before: https://sqlite.org/fts5.html#fts5_prefix_queries If possible, can you trim the database down to just two rows that demonstrate the problem and upload it somewhere? i.e. so that it contains two rows that should both be matched by 'أعلم*', but for which the current FTS5 only matches one. Even if the complete database makes the problem obvious to Arabic readers, it will be quite difficult for non-readers to deal with. Thanks, Dan. On Tue, Sep 11, 2018 at 10:20 AM Sandu Buraga wrote: In Arabic you have a different direction of the text. Might be that the reason? Sandu Eric Minbiole schrieb am Di., 11. Sep. 2018, 00:23: SELECT rowid,text FROM table WHERE table MATCH 'أعلم*'; And I have to add this that my data is Arabic text. This method must find words that contains 'أعلم' but it doesn't. What should I do now. I just tried this in SQLite version 3.24.0 on a Mac, and it seems to work. Please see my example below. In particular, the first select doesn't have a *, so it doesn't find the word. The second example includes a trailing *, so it performs a "starts with" search, and does find the match. (Note that I simply doubled the letters of your original arabic text to make a longer word.) MacBook-II:Programs eric$ ./sqlite3 SQLite version 3.24.0 2018-06-04 19:24:41 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite> CREATE VIRTUAL TABLE fts USING fts5(doc); sqlite> INSERT INTO fts (rowid, doc) VALUES (1, 'english text'); sqlite> INSERT INTO fts (rowid, doc) VALUES (2, 'arabic أعلمأعلم'); sqlite> SELECT rowid FROM fts WHERE fts MATCH 'أعلم'; sqlite> SELECT rowid FROM fts WHERE fts MATCH 'أعلم*'; 2 sqlite> One possible explanation: You mentioned that you want a "contains" search. However, the trailing asterisk in your example only results in a "begins with" search. If you really want a "contains" search, you'll need to put the * at both the beginning and end of the match word. E.g., "WHERE fts MATCH '*asdf*'; Hope this is helpful. ~Eric ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] The server https://www3.sqlite.org/ is not working
On Sep 11, 2018, at 2:29 AM, Domingo Alvarez Duarte wrote: > > I think that could be a good idea to add an option to fossil update command > to allow override the url for the repository so in cases like today I could > do: > > fossil updata --url https://www1.sqlite.org/cgi/src There are already two ways to do that. Using the method I prefer from within a Fossil checkout of a repo cloned from www3: $ fossil sync https://www1.sqlite.org/cgi/src To do it from outside the checkout directory, point Fossil at the cloned reop with -R. The second method is to set the new URL separately using the "fossil remote-url” command, then update, sync, push, pull, etc. Either way, the new URL is used for all future updates. You’d have to give the www3 URL with these commands to switch back later. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] SQLite version 3.25.0 enters release testing
We are in final testing for SQLite 3.25.0. Details on this release can be seen at https://www.sqlite.org/draft/releaselog/3_25_0.html There will be no further enhancements before the release. Bug fixes only. You can follow the progress of testing at https://www.sqlite.org/checklists/325/index When the checklist above goes all green, we will cut the release. If you have any issues or concerns with the forthcoming 3.25.0 release, please bring them to my attention quickly. Thank you. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] [sqlite-dev] SQLite version 3.25.0 enters release testing
> On Sep 11, 2018, at 8:07 PM, Richard Hipp wrote: > > We are in final testing for SQLite 3.25.0. Details on this release > can be seen at > > https://www.sqlite.org/draft/releaselog/3_25_0.html Window Functions! Hurray! Hurray! :) https://www.sqlite.org/draft/windowfunctions.html ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] [sqlite-dev] SQLite version 3.25.0 enters release testing
Wow, ALTER TABLE RENAME COLUMN is going to help KEXI, thanks for that! On Tue, 11 Sep 2018 at 20:07, Richard Hipp wrote: > We are in final testing for SQLite 3.25.0. Details on this release > can be seen at > > https://www.sqlite.org/draft/releaselog/3_25_0.html > > There will be no further enhancements before the release. Bug fixes > only. You can follow the progress of testing at > > https://www.sqlite.org/checklists/325/index > > When the checklist above goes all green, we will cut the release. > > If you have any issues or concerns with the forthcoming 3.25.0 > release, please bring them to my attention quickly. Thank you. > > -- > D. Richard Hipp > d...@sqlite.org > ___ > sqlite-dev mailing list > sqlite-...@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-dev > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite version 3.25.0 enters release testing
On Tue, 11 Sep 2018 at 11:08, Richard Hipp wrote: > > We are in final testing for SQLite 3.25.0. Details on this release > can be seen at > > https://www.sqlite.org/draft/releaselog/3_25_0.html > > There will be no further enhancements before the release. Bug fixes > only. You can follow the progress of testing at > > https://www.sqlite.org/checklists/325/index > Both of those webpages look really nice on mobile browsers! ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] SQLITE touches unchanged expression indexes on update
It seems like there is an opportunity for improvement on updates if an index contains expressions. In the following example: CREATE TABLE Foo(x, y, z); CREATE INDEX FooX on Foo(x); CREATE INDEX FooZ on Foo(z); CREATE INDEX FooLenZ on Foo(length(z)); explain UPDATE foo SET x=1 WHERE rowid=1; I see the plan below. Notice it's updating FooLenZ even though the 'UPDATE foo SET x=1' statement doesn't touch the Z column at all. It doesn't try to update FooZ, just FooLenZ, but both should be untouched. RecNo addr opcode p1 p2 p3 p4p5 comment - --- -- -- -- - -- --- 1 0Init0 30 000 (null) 2 1Null0 7 800 (null) 3 2OpenWrite 0 2 0 3 00 (null) // opening 'Foo' (expected) 4 3Integer 1 12 000 (null) 5 4SeekRowid 0 6 12 00 (null) 6 5Rowid 0 8 000 (null) 7 6OpenWrite 1 5 0 k(2,,)00 (null) // opening 'FooLenZ' (NOT expected) 8 7OpenWrite 3 3 0 k(2,,)00 (null) // opening 'FooX' (expected) 9 8IsNull 8 29 000 (null) 10 9Integer 1 9 000 (null) 11 10 Column 0 1 10 00 (null) 12 11 Column 0 2 11 00 (null) 13 12 Copy11 13 000 (null) 14 13 Function0 0 13 2 length(1) 01 (null) 15 14 IntCopy 8 3 000 (null) 16 15 MakeRecord 2 2 100 (null) 17 16 SCopy 9 5 000 (null) 18 17 IntCopy 8 6 000 (null) 19 18 MakeRecord 5 2 400 (null) 20 19 Copy11 13 000 (null) 21 20 Function0 0 13 14 length(1) 01 (null) 22 21 Rowid 0 15 000 (null) 23 22 IdxDelete 1 14 200 (null) 24 23 Column 0 0 14 00 (null) 25 24 IdxDelete 3 14 200 (null) 26 25 IdxInsert 1 1 2 2 00 (null) // updating 'FooLenZ' (NOT expected) 27 26 IdxInsert 3 4 5 2 00 (null) // updating 'FooX' (expected) 28 27 MakeRecord 9 3 13 00 (null) 29 28 Insert 0 13 8 Foo 05 (null) 30 29 Halt0 0 000 (null) 31 30 Transaction 0 1 42 0 01 (null) 32 31 Goto0 1 000 (null) sqlite_master: RecNo type nametbl_name rootpage sql - - --- -- 1 table Foo Foo 2 CREATE TABLE Foo(x, y, z) 2 index FooXFoo 3 CREATE INDEX FooX on Foo(x) 3 index FooZFoo 4 CREATE INDEX FooZ on Foo(z) 4 index FooLenZ Foo 5 CREATE INDEX FooLenZ on Foo(length(z)) ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Draft: Window Functions
In https://www.sqlite.org/draft/windowfunctions.html: "Window functions may only appears in the result set and..." s/appears/appear/ "If default is also provided, then it is returned instead of NULL if row identified by offset does not exist." s/if row/if the row/# 2 places - both lead() and lag() functions -- Mark Lawrence ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
