On 10/27/2014 01:49 PM, Tristan Van Berkom wrote:
This is just a request-for-enhancement bug report, I've went to the
trouble or reproducing this problem in a simple test case and while
I probably wont be able to immediately benefit from an upstream fix
for this, I hope that this bug report will
Tristan Van Berkom wrote:
> locateFKeyIndex() function issuing the not-so-informative
> message "foreign key mismatch" [...]
>
> o When foreign keys are enabled at CREATE TABLE time, it would
> be very helpful at this point to issue an error if a foreign
> key is declared which refers to
On 27 Oct 2014, at 8:17am, Clemens Ladisch wrote:
> Tristan Van Berkom wrote:
>> locateFKeyIndex() function issuing the not-so-informative
>> message "foreign key mismatch" [...]
>>
>> o When foreign keys are enabled at CREATE TABLE time, it would
>>be very helpful at this point to issue a
SQLite treats each attached database as a separate entity. Attaching the same
file twice is just asking for problems.
The query specifies that the destination db be locked for write and the source
db for read; which translates to two locks that cannot coexist on one
underlying db file.
-Ur
On Mon, Oct 27, 2014 at 9:23 AM, Hick Gunter wrote:
> SQLite treats each attached database as a separate entity. Attaching the
> same file twice is just asking for problems.
>
> The query specifies that the destination db be locked for write and the
> source db for read; which translates to two l
On Mon, 2014-10-27 at 09:17 +0100, Clemens Ladisch wrote:
> Tristan Van Berkom wrote:
> > locateFKeyIndex() function issuing the not-so-informative
> > message "foreign key mismatch" [...]
> >
> > o When foreign keys are enabled at CREATE TABLE time, it would
> > be very helpful at this point
On 27 Oct 2014, at 8:43am, Stephan Beal wrote:
> - a couple months back Simon suggested ATTACHing the db to itself so that
> we can effectively alias "main" to the well-known name we have specified
> for that db instance. It worked like a charm until Dave discovered this
> weird locking behaviou
On Mon, Oct 27, 2014 at 9:58 AM, Simon Slavin wrote:
>
> On 27 Oct 2014, at 8:43am, Stephan Beal wrote:
>
> > - a couple months back Simon suggested ATTACHing the db to itself so that
> > we can effectively alias "main" to the well-known name we have specified
> > for that db instance. It worked
[Changing subject line as this strays away from the original topic]
On Mon, 2014-10-27 at 08:22 +, Simon Slavin wrote:
> On 27 Oct 2014, at 8:17am, Clemens Ladisch wrote:
>
> > Tristan Van Berkom wrote:
> >> locateFKeyIndex() function issuing the not-so-informative
> >> message "foreign key
On 27 Oct 2014, at 9:11am, Tristan Van Berkom wrote:
> This seems to me to be an elegant solution, but I'd be curious to
> know if it would be considered badly designed for some reason, and
> would be interested to know what kind of alternatives people would
> propose.
A foreign key which point
How about always referencing all tables via attached db names? That way, "main"
is never referenced, neither explicitly nor implicitly, and is therefore never
locked.
-Ursprüngliche Nachricht-
Von: Stephan Beal [mailto:sgb...@googlemail.com]
Gesendet: Montag, 27. Oktober 2014 09:43
An: G
On Mon, Oct 27, 2014 at 10:44 AM, Hick Gunter wrote:
> How about always referencing all tables via attached db names? That way,
> "main" is never referenced, neither explicitly nor implicitly, and is
> therefore never locked.
>
It's looking more and more as if that's what we'll have to do, but i
On Mon, Oct 27, 2014 at 11:08 AM, Stephan Beal
wrote:
> - TEMP tables get created in the MAIN db (assuming my memory of the docs
> is correct), which means we can (though accidental misuse or carelessness)
> end up filling up RAM with temporary tables (which we use regularly to
> process large da
TEMP tables get created in database temp; which is located in "a file" or "in
memory" depending on the SQLITE_TEMP_STORE preprocessor symbol and the pragma
temp_store.
-Ursprüngliche Nachricht-
Von: Stephan Beal [mailto:sgb...@googlemail.com]
Gesendet: Montag, 27. Oktober 2014 11:44
An:
On Mon, Oct 27, 2014 at 11:53 AM, Hick Gunter wrote:
> TEMP tables get created in database temp; which is located in "a file" or
> "in memory" depending on the SQLITE_TEMP_STORE preprocessor symbol and the
> pragma temp_store.
>
Which reveals my ignorance on the topic ;). IIRC we aren't using a
Just to be clear. It basically means that after MATCH records are returned
it iterates through ALL the rowids of the returned set and removes them from
the set and orders them accordingly.
--
View this message in context:
http://sqlite.1065341.n5.nabble.com/FTS-pagination-tp78754p78849.html
Se
I have a database that is updated (written) by one user and read by
another user. So I use WAL mode to get concurrency. I'm running
Linux/ext4.
Both users are members of the same group. The trouble is that Linux
ignores the setgid bit on the directory, so when a user access the
database, they w
On Mon, Oct 27, 2014 at 4:19 AM, Simon Slavin wrote:
> A foreign key which points to the same table had not occurred to me, outside
> of abstract mathematical exercises. I think you've come up with an
> acceptable example of why I felt reluctant to condemn the practise.
If you can do a self-jo
On Mon, 27 Oct 2014 12:33:59 +0100
Steinar Midtskogen wrote:
> Is there a way to prevent the -wal and -shm files from being deleted
> after use, so that I can have them always have the right group? Or is
> there a way to tell Linux to observe the setgid flag on a directory
> (ext4)?
See -o grpi
Andrea, any chance I can download the latest version of the DLL?
thanks
gert
2014-09-28 23:28 GMT+02:00 aperi2007 :
> Hi Keith,
> thx for hints.
> I have apply all of them.
>
> The only one I like to explain:
>
> I know the warning for the void insted of int declaration of
> stringmetricsFunc.
Sorry, stupid me... I clicked on the wrong link.
2014-10-27 17:32 GMT+01:00 Gert Van Assche :
> Andrea, any chance I can download the latest version of the DLL?
>
> thanks
>
> gert
>
> 2014-09-28 23:28 GMT+02:00 aperi2007 :
>
>> Hi Keith,
>> thx for hints.
>> I have apply all of them.
>>
>> The o
"James K. Lowden" writes:
> See -o grpid in mount(8). I think that's what you want.
Thanks. It works!
--
Steinar
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
On Mon, 2014-10-27 at 12:27 -0400, James K. Lowden wrote:
> On Mon, 27 Oct 2014 12:33:59 +0100
> Steinar Midtskogen wrote:
>
> > Is there a way to prevent the -wal and -shm files from being deleted
> > after use, so that I can have them always have the right group? Or is
> > there a way to tell
I am using SQLite on a small webproject and I usually use MySQL.
As we know in MySQL there is a user/pass authentication to the DB.
In the File tree onthe SQLite site I can see in the /ext directory the userauth
folder.
It seems like this is not enabled by default.
So I started reading the
On Mon, Oct 27, 2014 at 11:59 AM, Stephan Beal
wrote:
> On Mon, Oct 27, 2014 at 11:53 AM, Hick Gunter wrote:
>
>> TEMP tables get created in database temp; which is located in "a file" or
>> "in memory" depending on the SQLITE_TEMP_STORE preprocessor symbol and the
>> pragma temp_store.
>>
>
> W
On Mon, Oct 27, 2014 at 3:23 AM, Hick Gunter wrote:
> SQLite treats each attached database as a separate entity. Attaching the same
> file twice is just asking for problems.
Well, it could do something to detect duplicates, but it may not be
easy (or even possible) to portably detect that two DB
On Mon, Oct 27, 2014 at 8:52 PM, Nico Williams
wrote:
> Well, it could do something to detect duplicates, but it may not be
> easy (or even possible) to portably detect that two DB files are the
> same file.
The same is true for the application, of course, but it
> seems reasonable [to me anyway
On Mon, Oct 27, 2014 at 3:17 PM, Stephan Beal wrote:
> That's conceptually the same problem we're trying to solve here: keep the
> public db names stable, regardless of where/how they're actually attached.
Yes, I think that's desirable.
If it's not too much to ask for then SQLite3 ought to: a) c
On 27 Oct 2014, at 9:49pm, Nico Williams wrote:
> On Mon, Oct 27, 2014 at 3:17 PM, Stephan Beal wrote:
>> That's conceptually the same problem we're trying to solve here: keep the
>> public db names stable, regardless of where/how they're actually attached.
>
> Yes, I think that's desirable.
>
On Mon, Oct 27, 2014 at 5:12 PM, Simon Slavin wrote:
> On 27 Oct 2014, at 9:49pm, Nico Williams wrote:
>> If it's not too much to ask for then SQLite3 ought to: a) check for
>> duplicates by canonicalized path (but keep in mind that this can be
>> difficult to do portably, or without obnoxious le
On Mon, 27 Oct 2014 16:49:42 -0500
Nico Williams wrote:
> If it's not too much to ask for then SQLite3 ought to: a) check for
> duplicates by canonicalized path (but keep in mind that this can be
> difficult to do portably, or without obnoxious length limitations on
> Windows),
The name is not
31 matches
Mail list logo