Are you compiling the SQLite shell utility, or just the library? The
Windows and Linux versions of the lib available from the download page
which are compiled with all the optional features are 235kb and 205kb
respectively. It's surprising that the compiled version for AVR32 is
more than twice
On 2008 October 29 (Wed) 03:26:45pm PDT, James Sheridan <[EMAIL PROTECTED]>
wrote:
> Related addendum:
>
> In reading it appears that MySQL treats "," as a CROSS JOIN and implements it
> effectively as an INNER JOIN.
> a) Is this correct?
Not really, no.
MySQL treats "," as a CROSS JOIN,
On a large table it will be much faster to use an index than to force a
row scan as your initial query did.
L B wrote:
> I have obtained a great performance improvement now
> just adding an index in the 2 columns
>
> dtfrom and idcatalogue,
>
> removing the 2 single indexes on the column
James Sheridan
<[EMAIL PROTECTED]> wrote:
> The query should have been:
>
> SELECT Q.*
> FROM Query Q,
> UserQuery UQ
> WHERE Q.type = 'a' OR
> (Q.id = UQ.queryID AND
> UQ.userID = '1');
Well, it's the same thing: for each row in Q with Q.type = 'a', you will
get as many copies of this row as
James Sheridan wrote:
> CREATE TABLE [Query] (
> [id] INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
> [creatorID] INTEGER NOT NULL,
> [ownerID] INTEGER NOT NULL,
> [type] VARCHAR NOT NULL
> );
> CREATE TABLE [UserQuery] (
> [userID] INTEGER NOT NULL,
>
James Sheridan
<[EMAIL PROTECTED]> wrote:
> CREATE TABLE [Query] (
> [id] INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
> [creatorID] INTEGER NOT NULL,
> [ownerID] INTEGER NOT NULL,
> [type] VARCHAR NOT NULL
> );
> CREATE TABLE [UserQuery] (
> [userID] INTEGER NOT NULL,
> [queryID] INTEGER NOT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pados Károly wrote:
> How could I make it even smaller?
http://article.gmane.org/gmane.comp.db.sqlite.general/24080
http://www.hwaci.com/sw/sqlite/prosupport.html
Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
CREATE TABLE [Query] (
[id] INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
[creatorID] INTEGER NOT NULL,
[ownerID] INTEGER NOT NULL,
[type] VARCHAR NOT NULL
);
CREATE TABLE [UserQuery] (
[userID] INTEGER NOT NULL,
[queryID] INTEGER NOT NULL
);
Hello!
I'd like to use SQLite on an embedded AVR32 system, the flash program memory
being 256kBytes. According to the docs it is possible to reduce the size of the
compiled binary to 180KB, but I just cannot get close enough. The best I get is
485Kbytes with omitting every optional feature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
MikeW wrote:
> Having looked at the source code, looks like the best way to do this
> /would/ be to add another (!) numerical parameter to sqlite3ErrorMsg()
> indicating
> the extended error code that corresponds with the message.
Julian Bui <[EMAIL PROTECTED]> writes:
>
> >
> > See "PRAGMA cache_size". If you're working on a modern desktop with
> > a comfortable amount of RAM, it isn't unreasonable to increase the
> > cache size by an order of magnitude or two (default is 2000).
> >
>
> I forgot to mention I use
2008/10/29 Shaun R. <[EMAIL PROTECTED]>:
> The rowid looks to reuse numbers when a row is deleted, how can i stop this?
>
> For example, i insert 3 rows, then i delete row 2, when entering a new row
> after that the rowid is 2 rather than 4. I want the rowid to be 4.
use AUTOINCREMENT keyword:
Use an autoincrement field in the table instead.
On Wed, 2008-10-29 at 09:46 -0700, Shaun R. wrote:
> The rowid looks to reuse numbers when a row is deleted, how can i stop this?
>
> For example, i insert 3 rows, then i delete row 2, when entering a new row
> after that the rowid is 2 rather
Shaun R. <[EMAIL PROTECTED]> wrote:
> The rowid looks to reuse numbers when a row is deleted, how can i
> stop this?
create table t(id integer primary key autoincrement, ...);
http://sqlite.org/autoinc.html
Igor Tandetnik
___
sqlite-users mailing
The rowid looks to reuse numbers when a row is deleted, how can i stop this?
For example, i insert 3 rows, then i delete row 2, when entering a new row
after that the rowid is 2 rather than 4. I want the rowid to be 4.
~Shaun
___
sqlite-users
>
> See "PRAGMA cache_size". If you're working on a modern desktop with
> a comfortable amount of RAM, it isn't unreasonable to increase the
> cache size by an order of magnitude or two (default is 2000).
>
I forgot to mention I use JDBC to access sqlite from a java app. Is there
an
Thanks for replies everyone.
Actually, I don't include the code but I do make a very small mention of
using batch inserts w/ a transaction ("> //every dataInsertPs gets added to
a batch and committed every 1000 records").
I am using JDBC so I do not use BEGIN and END statements. Do I need to
Julian Bui <[EMAIL PROTECTED]> writes:
>
> Hey MikeW,
>
> The article you posted seems like something I might want to try. I am
> currently using JDBC to embed sqlite in my java app. Do you know if there
> are equivalent statements for java?
>
> Please let me know if you do.
>
> Thanks,
>
On Wed, Oct 29, 2008 at 06:10:56AM -0600, John Stanton scratched on the wall:
> The Sqlite B-Tree indices do slow down on insertion as extra levels are
> created in the index as it grows large. That is an inherent feature of
> such structures.
This can often be mitigated by increasing the
MikeW <[EMAIL PROTECTED]> writes:
...
> But without a suitable extended error number, that is what I think is the only
> solution ...
> would be nice to have sqlite3_ext_errcode() to get a better view.
>
> (The existing extended error code system is restricted to I/O errors ...)
>
> Any better
Hi yoky,
2008/10/29 yoky <[EMAIL PROTECTED]>:
> Hi all,
>I create a table with 250 columns and this table has 3 records, I
> want to select the records from the table which satisfy certain conditions.
> the SQL statement like this:
>select * from tablename where (conditions);
>
Hi all,
I create a table with 250 columns and this table has 3 records, I
want to select the records from the table which satisfy certain conditions.
the SQL statement like this:
select * from tablename where (conditions);
Then use sqlite3_get_table() function to get the
I have obtained a great performance improvement now
just adding an index in the 2 columns
dtfrom and idcatalogue,
removing the 2 single indexes on the column dtfrom and
idcatalogue.
I could not believe, now the query
SELECT MAX(DTFROM) AS MAXDT, IDCATALOGUE FROM
CRONOCATALOGUES GROUP BY
thanks, BareFeet. I will give this a try tomorrow.
Igor,
I tried to reply to your email, but somehow, I can not reply to newsgroup.
Weird. But, the relationship is login.
thanks,
josé
- Original Message -
From: "BareFeet" <[EMAIL PROTECTED]>
To: "General Discussion of SQLite
On Tue, Oct 28, 2008 at 4:31 PM, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
> In order to provide a work-around we need to understand the problem.
> I have no explanation for the observed behavior.
>
> Have you tried running "PRAGMA integrity_check" against the database
> as a normal user?
>
I have investigated more.
It seems that the performance problem is simply
related to the query:
SELECT MAX(DTFROM) AS MAXDT, IDCATALOGUE FROM
CRONOCATALOGUES GROUP BY IDCATALOGUE
which takes at first execution 9 seconds in access and
30 seconds in sqlite, and it takes, after first
execution (OS
Eduardo Morras wrote:
> At 13:10 29/10/2008, you wrote:
>
>> Look up the implications of Sqlite's ACID feature and the use of
>> transactions. COMMITs are tied to disk rotation speed. On our Sqlite
>> databases where we look for performance we use 15,000 rpm disks and are
>> diligent in
The return code from an sqlite function (also from sqlite3_errcode()) is very
general, for example including many different conditions under SQLITE_ERROR.
However, the message returned from sqlite3_errmsg() does convey more
information,
so the detail is obviously there somewhere.
But using this
At 13:10 29/10/2008, you wrote:
>Look up the implications of Sqlite's ACID feature and the use of
>transactions. COMMITs are tied to disk rotation speed. On our Sqlite
>databases where we look for performance we use 15,000 rpm disks and are
>diligent in wrapping INSERTs, UPDATEs and DELETEs in
Look up the implications of Sqlite's ACID feature and the use of
transactions. COMMITs are tied to disk rotation speed. On our Sqlite
databases where we look for performance we use 15,000 rpm disks and are
diligent in wrapping INSERTs, UPDATEs and DELETEs in transactions and
get very good
The most common reason which comes up here time and again is that the
inserts are wrapped in a transaction. See BEGIN, END statements in the
Docs. You haven't mentioned whether you are using a transaction, so I
may be misguided in my reply. But the sample code doesn't!
Wednesday, October 29,
Hi everyone,
First off, I'm a database and sqlite newbie. I'm inserting many many
records and indexing over one of the double attributes. I am seeing
my insert times slowly degrade as the database grows in size until
it's unacceptable - less than 1 write per millisecond (other databases
have
32 matches
Mail list logo
