I have a table structure like this:
CREATE TABLE padstack (
id INTEGER PRIMARY KEY AUTOINCREMENT,
pin_number INTEGER,
name TEXT
);
Is there any way to get the 'id' of newly inserted row? My insert of course
not contains the 'id' field.
Thanks,
Lev
At 21:11 27/08/2015, you wrote:
> > There are 2 distinct and volontary function invokations, so I don't see
> > how SQL engine would decide not to perform the second call.
>
>Agreed, though I'm pretty sure I've read messages in this thread at
>advocate the same function should return the same
At 23:25 27/08/2015, you wrote:
>---
>I have a table structure like this:
>
>CREATE TABLE padstack (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
> pin_number INTEGER,
> name TEXT
>);
>
>Is there any way to get the 'id' of newly inserted row? My insert of
>course
>not contains the 'id'
On Thu, 27 Aug 2015 23:40:15 +0200
Jean-Christophe Deschamps wrote:
> http://www.sqlite.org/c3ref/last_insert_rowid.html is what you need.
Yes, thanks a lot!
Lev
On 28 Aug 2015, at 3:15am, Yuri wrote:
> * Database is written into memory
> [...]
> How can I understand why the slowdown occurs? Especially, why the slowdown in
> so "sharp"?
Your computer has a certain amount of free memory. Once your database is
bigger than that size the computer has to
On 2015-08-28 04:15 AM, Yuri wrote:
> I build a fairly large DB, with major tables having 800k..5M rows,
> with several relationships between tables.
>
> At ~30% into the insertion process it slows down rapidly. Records
> #171k..172k are still fast, and records #172k...173k are already ~10
>
On 28 Aug 2015, at 3:45am, Yuri wrote:
> My computer has 24GB ob RAM of which 4GB is free. At the time of the problem
> the size of the process is 325MB. And the size of complete DB is ~250MB. So
> this isn't it.
>
> What's worth mentioning though is that at the time of the event in question
Thanks to everybody who made suggestions.
There was the legitimate constraint violation caused by a bug in an
importing program. Program was erroneously inserting zero integer into
the field that is both the leading part of the primary key (possibly
causing its non-uniqueness), and a foreign
Yuri wrote:
> I followed every advise I could find:
> * Database is written into memory
> * Whole insertion happens in one transaction in one giant BEGIN TRANSACTON;
> ... END TRANSACTION; block.
> * Foreign keys are deferred: PRAGMA defer_foreign_keys=ON;
> * Journal is disabled: PRAGMA
Jean-Christophe Deschamps wrote:
> At 21:11 27/08/2015, you wrote:
>> I think it still comes back to my earlier comment: Would changing it to
>> behave more like the most common / expected outcome above be a breaking
>> change?
>
> Looks like "How many zillion devices are going to misbehave if
Slightly off topic, but I am looking at version control systems. SQLite
looks like it is using Fossil. How does Fossil compare to using Git,
Mercurial, or Subversion?
-
Scott Doctor
scott at scottdoctor.com
-
On Fri, Aug 28, 2015 at 9:56 AM, Scott Doctor wrote:
> Slightly off topic, but I am looking at version control systems. SQLite
> looks like it is using Fossil. How does Fossil compare to using Git,
> Mercurial, or Subversion?
>
http://fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki ? --DD
At 09:14 28/08/2015, you wrote:
>---
> > Looks like "How many zillion devices are going to misbehave if this
> is fixed?"
>
>We will find out, because SQLite was changed two days ago:
>http://www.sqlite.org/cgi/src/info/c2f3bbad77850468
>---
Fine, let's sit down and watch the world collapse.
Now that we have solved the expression column reevaluation problem on the
"ORDER BY" clause what about the same problem on the "WHERE" clause ?
CREATE TABLE myTable (a INTEGER);
INSERT INTO myTable VALUES (1),(2),(3),(4),(5);
CREATE VIEW myView AS SELECT a,random()%100 AS rr FROM myTable;
On 08/26/2015 09:03 PM, Richard Hipp wrote:
> Time stands still for multiple rows, as long as they are within the
> same sqlite3_step() call. For example, if you run:
>
> CREATE TABLE t1(a DATETIME);
> WITH RECURSIVE
> c(x) AS (VALUES(1) UNION ALL SELECT x+1 FROM c WHERE
Hello
The Sqlite3.exe CLP has features like .dump, .schema, .read, .output, etc.
Can I use through sqlite3.dll functions?. Some examples and/or information,
please
Best regards
On Fri, Aug 28, 2015 at 12:15 PM,
wrote:
> The Sqlite3.exe CLP has features like .dump, .schema, .read, .output, etc.
>
> Can I use through sqlite3.dll functions?.
No. They are features of sqlite3.exe, not the DLL.
> Some examples and/or information, please
>
You'll need to port them into
Yahoo! Mail wrote:
> sqlite> drop table if exists t1; create table t1(a datetime); begin; with
> recursive c(x) as (values(1) union all select x + 1 from c where x <
> 10) insert into t1(a) select datetime('now') from c; commit;
>
> It would take ages to finish and that is logical; it's
Obviously you did not get my issue; something is wrong and your timer
suggestion indicates this. During the execution of each command, I would
monitor it with *watch "du test.db*"*. The journal size would go mad
even surpassing the database's actual size at some moments.
*sqlite> .timer on
OK, I am truly grateful for what I have learned in this thread! And I have
composed an new, personal, rule: don't use a function in _anything_ other
than in the column list portion of a SELECT statement. If necessary, this
means I will be using a CREATE TEMPORARY TABLE results type construct when
On 28 Aug 2015, at 10:20am, Domingo Alvarez Duarte wrote:
> Please remember that the "random" function here is only a detail the real
> problem is the "column expression" been reevaluated more than once.
Yes. When considering fixes for this problem one needs to also consider
On 2015-08-28 01:17 PM, Yahoo! Mail wrote:
> Obviously you did not get my issue; something is wrong and your timer
> suggestion indicates this. During the execution of each command, I
> would monitor it with *watch "du test.db*"*. The journal size would go
> mad even surpassing the database's
Hi,
just and update here.
It seems that the newer libraries perform worse when we use multiple worker
threads. I don't know why and I don't have time to investigate it any further.
We'll stay with the old 3.7.16.2 for now.
Thank you for your assistance.
--
Gruesse,
Jakub
-Original
Where did you see the vacuum happening inside the transaction? It's just
right before begin...anyway. It seems I'm unable to make clear the
actual "issue" of mine, but anyhow it's not a bit deal. I just wanted to
report what I have noticed, that's all.
On 08/28/2015 03:43 PM, R.Smith wrote:
>
Hello Jakub,
Windows user here. I use Sqlite to contain some fairly bulky data but
the tables that store this data are simple and the queries and indexes
are also simple. Using a 300 meg test file, I fed data into fresh DB's
using different versions of Sqlite including some of the ones you
listed
> On modern PCs, SQLite's page cache does not have a large effect because
> of the file cache of the OS, but you should do, e.g.,
> PRAGMA cache_size = -100;
> for a 1 GB cache (default is only a few MB).
Hitting the page cache is much cheaper as it does not involve a system call.
Try
I have noticed that SQLite Query Browser is running slower than other IDEs,
including SQLitespeed, for some reason. Even when each IDE is set to using
similar versions of the SQLite3.dll. We had a recursive query in SQB take 6
min, on other IDEs it would be less than 2 min.
My $0.02
On Fri, 28 Aug 2015 12:55:00 +
Jakub Zakrzewski wrote:
> Hi,
>
> just and update here.
> It seems that the newer libraries perform worse when we use multiple
> worker threads. I don't know why and I don't have time to investigate
> it any further. We'll stay with the old 3.7.16.2 for now.
On 2015-08-28 03:09 PM, Yahoo! Mail wrote:
> Where did you see the vacuum happening inside the transaction? It's
> just right before begin...anyway. It seems I'm unable to make clear
> the actual "issue" of mine, but anyhow it's not a bit deal. I just
> wanted to report what I have noticed,
On 2015-08-28 04:45 PM, Rousselot, Richard A wrote:
> I have noticed that SQLite Query Browser is running slower than other IDEs,
> including SQLitespeed, for some reason. Even when each IDE is set to using
> similar versions of the SQLite3.dll. We had a recursive query in SQB take 6
> min,
-Original Message-
From: Dominique Devienne
Sent: Friday, August 28, 2015 4:03 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Version Control
On Fri, Aug 28, 2015 at 9:56 AM, Scott Doctor wrote:
> Slightly off topic, but I am looking at version control systems.
R.Smith,
Thank you for the reply.
I'm pasting again the original message that explains which versions I
have tested on which Operating System.
/I have tested this code with version 3.8.10.2 using "DB Browser for
SQLite" and it would crash; the same with SQLite Manager that uses the
same
If you're talking about Database Browser for SQLite (formally named SQLite
Database Browser), at least at one time (version 3.5) it executed each query
twice, apparently the first time to figure out the return types, and the second
time to display the results (this caused me a certain amount of
On Fri, Aug 28, 2015 at 3:47 AM, Yahoo! Mail wrote:
>
>
> On 08/26/2015 09:03 PM, Richard Hipp wrote:
>
> Time stands still for multiple rows, as long as they are within the
>> same sqlite3_step() call. For example, if you run:
>>
>> CREATE TABLE t1(a DATETIME);
>> WITH RECURSIVE
>>
On Fri, 28 Aug 2015 14:45:26 +, "Rousselot, Richard A"
wrote:
> I have noticed that SQLite Query Browser is running slower
> than other IDEs, including SQLitespeed, for some reason.
> Even when each IDE is set to using similar versions of the
> SQLite3.dll. We had a recursive query in SQB
35 matches
Mail list logo
