Re: [sqlite] Does single thread SQLite have bugs?

On Oct 20, 2009, at 12:49 PM, TEZ wrote: > Hi > > When I ran "make test", some errors were shown. > Is it meaning that SQLite has bugs? In this case it means the test script is buggy. Not SQLite itself. Dan. > $ uname -a > Linux localhost.localdomain 2.6.27-43vl5 #1 SMP Sat Aug 15 22:17:55

[sqlite] Problems with SQLite under Cygwin

Hi to all, I'm new on this list. I'm working on an application that runs on a small ARM-LINUX device, too small to contain GCC. So I've installed Cygwin on my Win XP desktop PC. Cygwin has arm-linux.gcc installed. Compiling & link works fine. The exec is FTP'd to the ARM device. Works great.

Re: [sqlite] Problems with SQLite under Cygwin

just an idea - make sure you are crosscompiling and libsqlite3.a is for arm-linux and not for cygwin j.hermanussen wrote: > Hi to all, I'm new on this list. > > I'm working on an application that runs on a small ARM-LINUX device, too > small to contain GCC. So I've installed Cygwin on my Win XP

Re: [sqlite] index for a group by

> please could you let me know which index could be better or faster? For this particular query index on (t,a,b,c) or even on (t,a,b,c,d) would be better and cause the query to execute faster (of course if by conditions t>x1 and t also do you know by chance how to speed up the index creation?

Re: [sqlite] Problems with SQLite under Cygwin

Another idea: make sure that you're telling linker to link with libsqlite3.a - it cannot guess it for you. Pavel On Tue, Oct 20, 2009 at 6:13 AM, Michal Seliga wrote: > just an idea - make sure you are crosscompiling and libsqlite3.a is for > arm-linux and not for

Re: [sqlite] Ticket 3810: SQLITE_ERROR on concurrent CREATE TEMP TRIGGER and sqlite3_close()

Hi Roger Your point about the preprocessor definitions is well-taken - I use them to optimize for my environment but they are not pertinent to the ticket. I recompiled sqlite3.c without all the definitions mentioned in the ticket (except -DSQLITE_OS_UNIX=1) and was still able to reproduce the

[sqlite] Question about the update of tuples in sqlite-views

Hello, i have a question about the update machanism for tuples in different views: For example from a table we have three different views. How will be the view updated if one Tuple updated or changed from the DB? (a) only the particular Tuple updated in the different view? (b) or updated the

Re: [sqlite] Question about the update of tuples in sqlite-views

Hi, a view does not need to be updated. Think of a view as a stored select statement. Martin Koston, Thorsten (ICT) wrote: > Hello, > > i have a question about the update machanism for tuples in different > views: > > For example from a table we have three different views. > How will be the

Re: [sqlite] Question about the update of tuples in sqlite-views

Views don't have any particular materialization or storage, it's just a select statement that is merged into your query every time you select something from the view. So to answer your question only changed tuple in the table is updated physically, views don't need to be updated. But in practical

Re: [sqlite] Ticket 3810: SQLITE_ERROR on concurrent CREATE TEMP TRIGGER and sqlite3_close()

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Toll wrote: > Could you point me to the test case you referred to? Look near the bottom of the ticket where it lists the various checkins. [6955] is the test case. You can examine the current source in case that has changed at

Re: [sqlite] Infinity

thanks for the notes. After change "double infinity" to std::numeric_limits(), here is the output: 1.10e+00 inf -inf 3.30e+00 it is clear that the sqlite3 does store "infinity", and select statement can retrieve it as well. The "printf" of C++ prints "infinity" as literal "inf". Michael

Re: [sqlite] index for a group by

> Nothing in this process can be sped up. Actually, that isn't entirely true. While it always requires a full data scan, Some things can make the indexing part of the process faster. Since indexing is done basically using a comparative sort, anything that would speed up the sort, will speed up

[sqlite] PRAGMA scope

I'm reading about the different PRAGMA operations. Cache_size mentions that it is per-database connection. Page_size says it is per database (must be used before the database is created), which sounds like per-connection (ie if I create two databases, I'm guessing I need to set the page_size

Re: [sqlite] PRAGMA scope

database = the physical file itself database connection = a specific reference to the database, obtained using sqlite3_open page_size has to be set before the database is created (though I'm NOT entirely sure how you would execute the pragma before creating the database, since executing the

Re: [sqlite] PRAGMA scope

On Tue, Oct 20, 2009 at 1:33 PM, John Crenshaw wrote: > database = the physical file itself > database connection = a specific reference to the database, obtained > using sqlite3_open > > page_size has to be set before the database is created (though I'm NOT > entirely

Re: [sqlite] PRAGMA scope

Makes sense. I figured the master pages would have still been created at this point, but I suppose that is simple enough to deal with. John -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of P Kishor Sent: Tuesday, October 20,

Re: [sqlite] index for a group by

I want to notice, John, that my words are in context "I have table with a lot of data, I want to create a particular index on it, how can I do it quickly". In this context only your 5 bullet is applicable, I admit I've forgot about that. And I don't understand how can one split creating of index

[sqlite] Crash on freeing mutex in sqlite3.c

Although i have successfully opened the database several times, today I'm seeing crashes on this line when I use sqlite3_open_v2: sqlite3_mutex_free(sqlite3GlobalConfig.pInitMutex); Any ideas what I could be doing wrong to cause this crash ? Here is the exact way I'm using this C wrapper:

Re: [sqlite] Crash on freeing mutex in sqlite3.c

The only place I see this line in SQLite's code is sqlite3_initialize(). So your path given to sqlite3_open_v2() is completely irrelevant and FTR no other process "can have a mutex" so that it will lead to crash of your process. The problem is that your application corrupts memory. Run it under

Re: [sqlite] Crash on freeing mutex in sqlite3.c

I'm using ddd, its the GUI version of gdb. Are you saying that the file pathname is wrong ? When you say "path give to sqlite is completely irrelevant" do you mean "db_filename"? I printed this path out using the debugger and it looks correct. And you are correct, it does die in

Re: [sqlite] Why FTS3 has the limitations it does

Hi Scott, thanks for the reply. It seems to be that ticket 3950 was also closed (I actually opened this ticket using version 3.6.16). The reason for closure was that the bug seems to have disappeared in version 3.6.19. I have not checked it by myself as I have not installed 3.6.19, yet. I

Re: [sqlite] Crash on freeing mutex in sqlite3.c

When I say "path ... completely irrelevant" it means path doesn't cause the error and it doesn't matter at all what path you're giving - you can pass an empty path and the error will still persist. ddd or gdb or whatever debugger you use - it doesn't show you memory access errors in your program

Re: [sqlite] Crash on freeing mutex in sqlite3.c

ok, thanks, will try that. - Original Message - From: "Pavel Ivanov" To: "General Discussion of SQLite Database" Sent: Tuesday, October 20, 2009 3:24:59 PM GMT -06:00 US/Canada Central Subject: Re: [sqlite] Crash on freeing mutex in sqlite3.c

Re: [sqlite] Why FTS3 has the limitations it does

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wanadoo Hartwig wrote: > It seems to be that ticket 3950 was also closed > (I actually opened this ticket using version 3.6.16). The reason for > closure was that the bug seems to have disappeared It is actually closed. I'm the one who has been

Re: [sqlite] Crash on freeing mutex in sqlite3.c

Pavel, You're the man! If you are ever in Dallas let me know, I owe you lunch. Found my bug using valgrind and it had nothing to do with the mutex or sqlite. Kavita - Original Message - From: "Pavel Ivanov" To: "General Discussion of SQLite Database"

Re: [sqlite] Crash on freeing mutex in sqlite3.c

On Tue, 20 Oct 2009, Pavel Ivanov wrote: > To: General Discussion of SQLite Database > From: Pavel Ivanov > Subject: Re: [sqlite] Crash on freeing mutex in sqlite3.c > > When I say "path ... completely irrelevant" it means path doesn't > cause the

[sqlite] commit time

i have a simple join table containing two ids from two other tables. i have an index on each of the ids in the join table. CREATE TABLE ContentWordItem (word_id INT, item_id INT); CREATE INDEX idx_ContentWordItem_word ON ContentWordItem(word_id); // index to perform fast queries by

[sqlite] Questions about sqlite3_result_text*

Hi, The following details about text/blobs returns from scalar functions are unclear to me and I prefer doing things right. a) is it allowable for a scalar function to modify (in place) an input argument and return a pointer to modified argument with sqlite3_result_text? If yes, what

Re: [sqlite] commit time

Sounds like a great candidate for shared cache with PRAGMA read_uncommitted = true. If other threads may also need a write lock on that table, you should handle SQLITE_LOCKED by incrementing a waiter count and calling sqlite3_unlock_notify. The thread doing the inserting can check to see if

[sqlite] help in understanding sqlite_master output

I'm new to sqlite. Just started on a project that comes with a lot of pre-created tables. Trying to understand the data structure, I did: >sqlite3 dev.db >select * from sqlite_master; Some of the output of the above query is a bit confusing to me. I checked out the doc in

Re: [sqlite] help in understanding sqlite_master output

On Tue, Oct 20, 2009 at 11:50 PM, Andy wrote: > I'm new to sqlite. Just started on a project that comes with a lot of > pre-created tables. > > Trying to understand the data structure, I did: > >>sqlite3 dev.db >>select * from sqlite_master; > > Some of the output of the

Re: [sqlite] Questions about sqlite3_result_text*

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Christophe Deschamps wrote: > a) is it allowable for a scalar function to modify (in place) an input > argument No. > b) same question for unmodified arguments: is it possible to avoid > duplication > of an argument if the function

Re: [sqlite] Questions about sqlite3_result_text*

>You are trying really hard to overthink things :-) I simply found version c-1) in a widely spread extension and was surprised by this way of doing the return, unduly complicated and inefficient in my poor understanding, hence the question. ___

Re: [sqlite] Questions about sqlite3_result_text*

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Christophe Deschamps wrote: > >> You are trying really hard to overthink things :-) > > I simply found version c-1) in a widely spread extension and was > surprised by this way of doing the return, unduly complicated and > inefficient in my