Re: [sqlite] Database locking Error

I am checking for all the function.As of now i am not using sqlite3 time out but testing application will take decision accordingly to recall the operation based on type of error. On Wed, Aug 28, 2013 at 3:03 PM, Simon Slavin wrote: > > On 28 Aug 2013, at 9:24am, techi

Re: [sqlite] To BEGIN or not to BEGIN. That is the question...

On 8/28/2013 6:28 PM, jose isaias cabrera wrote: I know that if I am doing INSERTs and such, I need to, BEGIN; INSERT... END; No, you don't need to. You can, if you want to, but there's no reason to have to. But, do I need to begin if I am going to create a table? ie. BEGIN;

[sqlite] To BEGIN or not to BEGIN. That is the question...

Greetings. I know that if I am doing INSERTs and such, I need to, BEGIN; INSERT... END; But, do I need to begin if I am going to create a table? ie. BEGIN; CREATE TABLE tableName ( JobID integer primary key, SubProjID integer, ProjID integer ); END; Also, what other

Re: [sqlite] ISO-8601 date string and '>' comparison buggy

Zitat von Igor Tandetnik : SQLite doesn't have "datetime" data type. All these values are plain strings, and are compared as such. It just so happens that, if you use a suitable format consistently, usual string comparisons also order dates and times correctly. So,

Re: [sqlite] ISO-8601 date string and '>' comparison buggy

On 28 Aug 2013, at 10:04pm, Thomas Jarosch wrote: > INSERT INTO "horde_alarms" VALUES(1, '2013-08-28 22:00:00'); To conform to ISO-8601, the space between the date and time should be a capital T. Though that's not your problem, as Igor explained. Simon.

Re: [sqlite] ISO-8601 date string and '>' comparison buggy

On 8/28/2013 5:04 PM, Thomas Jarosch wrote: consider this stripped-down database: -- CREATE TABLE "horde_alarms" ("id" INTEGER PRIMARY KEY, "alarm_end" datetime); INSERT INTO "horde_alarms" VALUES(1, '2013-08-28 22:00:00'); -- These queries work fine:

[sqlite] ISO-8601 date string and '>' comparison buggy

Hi, consider this stripped-down database: -- CREATE TABLE "horde_alarms" ("id" INTEGER PRIMARY KEY, "alarm_end" datetime); INSERT INTO "horde_alarms" VALUES(1, '2013-08-28 22:00:00'); -- These queries work fine: -- sqlite> SELECT * FROM

Re: [sqlite] Path Length Limit on Windows

On Mon, Aug 26, 2013 at 10:39 AM, Markus Schaber wrote: > Having a closer look, this will only solve problems with pathes whose > UTF8-encoding is longer than MAX_PATH bytes, but not with pathes which > exceed the 260 character limit. > > The latest check-in on trunk adds a

Re: [sqlite] Different result from experimental query

Problem fixed here: http://www.sqlite.org/src/info/caab361ebe -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Patch - fix sqlite compilation on Mac OS X 10.4

In the sqlite3MemInit() function, sqlite uses OS X's OSAtomicCompareAndSwapPtrBarrier() function once. This function was introduced in Mac OS X 10.5, but 10.4 has 32-bit and 64-bit specific versions; the PtrBarrier version is simply designed to work with the size of pointers on both 32-bit and

Re: [sqlite] Different result from experimental query

http://www.sqlite.org/src/info/bc878246ea On Wed, Aug 28, 2013 at 10:20 AM, E.Pasma wrote: > An experimantal query, involving OUTER JOIN with BETWEEN and JOIN with a > combined OR and AND expression, does not return all expected rows. I tried > this just after SQLite

Re: [sqlite] Different result from experimental query

The query should indeed return one row. Sorry I forget to say that. The NOT NULL for id in table t does not make any difference. It was only added to rule out that it might make any difference.. op 28-08-2013 16:29 schreef Marc L. Allen op mlal...@outsitenetworks.com: > Looks like that should

Re: [sqlite] Different result from experimental query

Looks like that should return one row, yes? I wonder if operator precedence is broken for that query and the OR is binding higher than the AND. Also possible is that the NOT NULL for id in table t is messing up some query optimization with t2.id NOT NULL. -Original Message- From:

[sqlite] Different result from experimental query

An experimantal query, involving OUTER JOIN with BETWEEN and JOIN with a combined OR and AND expression, does not return all expected rows. I tried this just after SQLite 3.8.0. was released and found that the issue is particular to this version. At least it is alright in version 3.7.17.

Re: [sqlite] 3.8.0 Update

On 27 Aug 2013, at 10:03, James Pearson wrote: On 27 Aug 2013, at 9:43, Dan Kennedy wrote: On 08/27/2013 09:33 PM, James Pearson wrote: On 27 Aug 2013, at 8:19, Richard Hipp wrote: On Tue, Aug 27, 2013 at 10:15 AM, James Pearson wrote: I've just updated to SQLite 3.8.0

Re: [sqlite] Group by in sqlite 3.8 works a little differently depending on the spaces at the end

On Wed, Aug 28, 2013 at 5:11 PM, Igor Tandetnik wrote: > On 8/28/2013 8:57 AM, Max Vlasov wrote: > See the recent discussion at > > http://comments.gmane.org/gmane.comp.db.sqlite.general/83005 > > It's not about trailing spaces, but about whether Title in GROUP BY resolves >

Re: [sqlite] v3.8 .import misbehaves

On 28 Aug 2013, at 2:32pm, Simon Davies wrote: > On 28 August 2013 14:16, wrote: >> OK, now copy the data line several times, and you'll see there are errors >> for several lines, unrelated to the final CRLF (which I removed this next >> sample).

Re: [sqlite] v3.8 .import misbehaves

http://www.sqlite.org/src/info/b5617e4fda -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] v3.8 .import misbehaves

On 28 August 2013 14:16, wrote: > OK, now copy the data line several times, and you'll see there are errors > for several lines, unrelated to the final CRLF (which I removed this next > sample). > > -- data -- > "Year","Debt","GDP1","GDP2","RGDP","dRGDP","Infl","debtgdp" >

Re: [sqlite] v3.8 .import misbehaves

It turns out that CRLF may have something to do with it. I can get rid of the errors, either: 1. if I replace "" with nothing, OR 2. if I save the file as Linux style (LF only). -Original Message- From: to...@acm.org Sent: Wednesday, August 28, 2013 4:16 PM To: General Discussion

Re: [sqlite] v3.8 .import misbehaves

OK, now copy the data line several times, and you'll see there are errors for several lines, unrelated to the final CRLF (which I removed this next sample). -- data -- "Year","Debt","GDP1","GDP2","RGDP","dRGDP","Infl","debtgdp" "1833","","49.3275923134","","118.3483703666","","",""

Re: [sqlite] Group by in sqlite 3.8 works a little differently depending on the spaces at the end

On 8/28/2013 8:57 AM, Max Vlasov wrote: the following query (notice the space at the end of the 3rd string) Create table [TestTable] ([Title] TEXT); INsert into TestTable (Title) VALUES ('simple text'); INsert into TestTable (Title) VALUES ('simple text'); INsert into TestTable (Title) VALUES

Re: [sqlite] v3.8 .import misbehaves

On 28 August 2013 13:51, wrote: > I did. I just download the precompiled binaries for Windows, and this is > what I see (for that sample data file): > > C:\temp>sqlite3.exe > SQLite version 3.8.0 2013-08-26 04:50:08 > Enter ".help" for instructions > Enter SQL statements

Re: [sqlite] Group by in sqlite 3.8 works a little differently depending on the spaces at the end

FWIW, PostgreSQL 9.2.4 shows two rows, like sqlite 3.8.0. On Wed, Aug 28, 2013 at 7:57 AM, Max Vlasov wrote: > Hi, > > the following query (notice the space at the end of the 3rd string) > > Create table [TestTable] ([Title] TEXT); > INsert into TestTable (Title) VALUES

[sqlite] Group by in sqlite 3.8 works a little differently depending on the spaces at the end

Hi, the following query (notice the space at the end of the 3rd string) Create table [TestTable] ([Title] TEXT); INsert into TestTable (Title) VALUES ('simple text'); INsert into TestTable (Title) VALUES ('simple text'); INsert into TestTable (Title) VALUES ('simple text '); select Trim(Title)

Re: [sqlite] v3.8 .import misbehaves

I did. I just download the precompiled binaries for Windows, and this is what I see (for that sample data file): C:\temp>sqlite3.exe SQLite version 3.8.0 2013-08-26 04:50:08 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> .sep , sqlite> .import data tab

Re: [sqlite] v3.8 .import misbehaves

On 28 Aug 2013, at 1:25pm, to...@acm.org wrote: > Then, doing > .sep , > .import data tab > > gives error(s). Can't reproduce your fault though I'm on a different version and platform. Please make sure you are using those specific quote characters and not directional quotes, and such

Re: [sqlite] v3.8 .import misbehaves

On Wed, Aug 28, 2013 at 8:25 AM, wrote: > For example, here's a sample (header + one line of data) that fails -- a > lot more lines fail but I cut it down just to show the problem: > > "Year","Debt","GDP1","GDP2","**RGDP","dRGDP","Infl","debtgdp" >

Re: [sqlite] v3.8 .import misbehaves

For example, here's a sample (header + one line of data) that fails -- a lot more lines fail but I cut it down just to show the problem: "Year","Debt","GDP1","GDP2","RGDP","dRGDP","Infl","debtgdp" "1833","","49.3275923134","","118.3483703666","","","" Then, doing .sep , .import data tab gives

Re: [sqlite] CREATE INDEX and column order

On Tue, Aug 27, 2013 at 10:49 AM, Doug Nebeker wrote: > Does the order of columns in a WHERE clause matter, or will the query > optimizer look at them as a set and find the best index? > WHERE clause order does not matter. The optimizer looks at the terms of the WHERE

Re: [sqlite] CREATE INDEX and column order

Thanks Simon, that makes a lot of sense. Does the order of columns in a WHERE clause matter, or will the query optimizer look at them as a set and find the best index? (ignoring all the special cases) -Original Message- From: sqlite-users-boun...@sqlite.org

Re: [sqlite] v3.8 .import misbehaves

On Wed, Aug 28, 2013 at 7:24 AM, wrote: > When trying to load a data file with ,"", sequences (for empty field), > there are quote escape related errors. > Manually converting ,"", to ,, allows the file to be loaded. According to > RFC4180, the double quote is an escaped quote if

[sqlite] v3.8 .import misbehaves

When trying to load a data file with ,"", sequences (for empty field), there are quote escape related errors. Manually converting ,"", to ,, allows the file to be loaded. According to RFC4180, the double quote is an escaped quote if found inside a string. The leading quote should not be

Re: [sqlite] BETWEEN and explicit collation assignment

> -Original Message- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org] On Behalf > Of James K. Lowden > Sent: Tuesday, August 27, 2013 8:11 PM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] BETWEEN and explicit collation assignment > > On Mon, 26

Re: [sqlite] Database locking Error

On 28 Aug 2013, at 9:24am, techi eth wrote: > Yes, i am checking the return code. Just for the function that gives the error, or for the calls before that too ? And are you setting a timeout ? If so, for how long ? Simon. ___

Re: [sqlite] I/O error in sqlite3

Kindly let me know the reason for I/O error. WAL mode is creating problem on ARM target. Thanks.. On Tue, Aug 27, 2013 at 10:13 AM, techi eth wrote: > I have got the reason for I/O error: > > It is due to PRAGMA journal mode WAL. If I run with default journal mode > then

Re: [sqlite] Database locking Error

Yes, i am checking the return code. On Tue, Aug 27, 2013 at 5:09 PM, Simon Slavin wrote: > > On 27 Aug 2013, at 5:15am, techi eth wrote: > > > For read operation i am doing _prepare(), _step(), _finalize(). > > For all other operation i am doing