On 07/13/2011 07:18 AM, Victor Mayevski wrote:
> I am getting a "foreign key mismatch" in TCL in the following situation:
> #The system is Ubuntu 10.10 32bit, using ActiveState 8.6 32 bit TCL binaries
>
> % package require sqlite3
> 3.7.6.3
>
>
> #Two example tables:
> create table users (name prim
I am getting a "foreign key mismatch" in TCL in the following situation:
#The system is Ubuntu 10.10 32bit, using ActiveState 8.6 32 bit TCL binaries
% package require sqlite3
3.7.6.3
#Two example tables:
create table users (name primary key unique, pass not null)
create table users1 (name refer
Thank you again, Michael - a very interesting suggestion. I'm going to start
experimenting with your previous suggestion of a linked list. This is simple
and intuitive, and I can see it working very well. In fact it's a similar
principle to that used by Audacity, the open source audio editor, w
Hi,
Quoting the ranking function given in the appendix of the FTS3
documentation page (http://www.sqlite.org/fts3.html#appendix_a)
static void rankfunc(sqlite3_context *pCtx, int nVal, sqlite3_value **apVal){
int *aMatchinfo;/* Return value of matchinfo() */
...
...
aMatchinfo =
> Try ON (EA.ENTRY_ID = +E.ENTRY_ID)
Yes, that works indeed nicely.
Thanks for that.
I keep forgetting these non-standard SQL tricks.
RBS
On Tue, Jul 12, 2011 at 9:28 PM, Igor Tandetnik wrote:
> On 7/12/2011 3:39 PM, Bart Smissaert wrote:
>> Joining a large table (ENTRY_ATTRIBUTES) and a sma
On 7/12/2011 3:39 PM, Bart Smissaert wrote:
> Joining a large table (ENTRY_ATTRIBUTES) and a small table
> (BPNewENTRY) and putting the resulting records
> in a third table, BP3. Large table may have a few million records and
> small table a few hundred records.
> The join field is called ENTRY_ID
Have checked and missing analyze is indeed not the cause of this
difference in query speed.
RBS
On Tue, Jul 12, 2011 at 9:06 PM, Bart Smissaert
wrote:
>> it thinks that scanning the whole ENTRY_ATTRIBUTES table will read
>> about 54855 rows. And you say that it has much more rows.
>
> This part
> it thinks that scanning the whole ENTRY_ATTRIBUTES table will read
> about 54855 rows. And you say that it has much more rows.
This particular database has less rows, the millions I mentioned are
in a different
database. I think the figures are right, but will check.
> I think running ANALYZE o
> Now what surprises me is that this optimization is not done
> automatically by SQLite.
> I suppose I just over estimate the capabilities of the SQLite plan generator.
> Or, would this be something that could be improved?
It's very non-obvious optimization and I think other type of
optimization w
Joining a large table (ENTRY_ATTRIBUTES) and a small table
(BPNewENTRY) and putting the resulting records
in a third table, BP3. Large table may have a few million records and
small table a few hundred records.
The join field is called ENTRY_ID in both tables and this has a
non-unique index in the
On Tue, Jul 12, 2011 at 13:13:25 +0900, 박성근 wrote:
> I am trying to investigate .db-wal file gathered from sudden power off.
Why do you want to investigate it? When you open the db again and checkpoint
it, sqlite will apply all the transactions that managed to finish before the
power-off to the .d
On Tue, Jul 12, 2011 at 10:48 AM, Baruch Burstein wrote:
> These do not work with the amalgamation. How do I use these?
>
Some will, some won't. To use those that won't, you'll need to rebuild the
SQLite amalgamation with the options you want to use and import that new
amalagmation into the Foss
Add #include or #include "SomeHeader.h" to the top of the
amalgamation, then define them in SomeHeader.h?
-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Baruch Burstein
Sent: Tuesday, July 12, 2011 10:48 AM
To: General Discu
These do not work with the amalgamation. How do I use these?
On Tue, Jul 12, 2011 at 5:44 PM, Richard Hipp wrote:
> Here are some additional options you might try to minimize the SQLite size
> in Fossil:
>
> SQLITE_OMIT_ANALYZE
> SQLITE_OMIT_AUTOMATIC_INDEX
> SQLITE_OMIT_AUTOVACUUM
> SQLITE_OMIT
Here are some additional options you might try to minimize the SQLite size
in Fossil:
SQLITE_OMIT_ANALYZE
SQLITE_OMIT_AUTOMATIC_INDEX
SQLITE_OMIT_AUTOVACUUM
SQLITE_OMIT_BUILTIN_TEST
SQLITE_OMIT_DEPRECATED
SQLITE_OMIT_GET_TABLE
SQLITE_OMIT_INCRBLOB
SQLITE_OMIT_SHARED_CACHE
SQLITE_OMIT_UTF16
SQLITE_
On Tue, Jul 12, 2011 at 10:37 AM, Baruch Burstein wrote:
> The website (http://www.sqlite.org/about.html) says that sqlite can be
> compiled to under 300K. I am using mingw32, and with no configuration did I
> manage to get sqlite3.o below 400k. What compiler/compiler options are used
> to reach <
The website (http://www.sqlite.org/about.html) says that sqlite can be
compiled to under 300K. I am using mingw32, and with no configuration did I
manage to get sqlite3.o below 400k. What compiler/compiler options are used
to reach <300K?
___
sqlite-users
Yes I know (although I only got a 200k difference), but -O3 is about twice
as fast in my tests.
On Tue, Jul 12, 2011 at 4:22 PM, Stephan Beal wrote:
> On Tue, Jul 12, 2011 at 3:10 PM, Baruch Burstein >wrote:
>
> > I assume this is the same for sqlite3.dll or sqlite3.lib, but if not, I
> am
> >
On Tue, Jul 12, 2011 at 3:10 PM, Baruch Burstein wrote:
> I assume this is the same for sqlite3.dll or sqlite3.lib, but if not, I am
> interested in sqlite3.o (mingw32).
> How can I minimize the size of the library (compiling with -O3, since speed
> is my top concern, so different optimizations is
http://www.sqlite.org/compile.html
Read section 1.4 -- tells you all you need to know.
First thing you should do is see if there's any significant performance
difference with -Os instead of -O3.
You may be surprised.
Michael D. Black
Senior Scientist
NG Information Systems
Advanced
http://www.sqlite.org/compile.html#omitfeatures
Make sure you read all important notes and tested your app thoroughly.
Pavel
On Tue, Jul 12, 2011 at 9:10 AM, Baruch Burstein wrote:
> I assume this is the same for sqlite3.dll or sqlite3.lib, but if not, I am
> interested in sqlite3.o (mingw32)
I assume this is the same for sqlite3.dll or sqlite3.lib, but if not, I am
interested in sqlite3.o (mingw32).
How can I minimize the size of the library (compiling with -O3, since speed
is my top concern, so different optimizations is not an option)? If I know
there are parts of SQL I don't need in
I thought of another way to do your copy/cut/paste...
Assuming you keep the original audio around and use the levels I showed before.
create table sequence(level int,parent int,start int,end end);
insert into seqeunce values(1,0,0,-1); // note that -1 means "until end of
data".
See where
See FTS3 extension where the full-text index is stored in multi btree
in regular tables. Note: FTS2 is more simple.
--
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi
24 matches
Mail list logo
