Re: [sqlite] Database locking Error

2013-08-28 Thread techi eth
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 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.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


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

2013-08-28 Thread Igor Tandetnik

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;
 CREATE TABLE tableName
 (
 JobID integer primary key, SubProjID integer, ProjID integer
 );
END;


Same here.


Also, what other commands should I wrap with BEGINs and ENDs?


BEGIN starts an explicit transaction; END commits the same. You need an 
explicit transaction if you want to execute two or more statements 
atomically, so that either they all succeed, or one fails and then the 
database is rolled back to the original state.


If you don't start a transaction explicitly, then each statement is 
implicitly wrapped in its own transaction.

--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


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

2013-08-28 Thread jose isaias cabrera

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 commands should I wrap with BEGINs and ENDs?

Thanks so much for the support.  And Dr. Hipp, 3.8.0 rocks!

josé
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


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

2013-08-28 Thread Thomas Jarosch

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, don't mix and match the format with and without T in the middle.  
Choose one, and stick to it.


thanks for the quick explanation. Now that's what I would call a funny  
issue :)


I'll prepare an upstream horde fix.

Best regards,
Thomas

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


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

2013-08-28 Thread Simon Slavin

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.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


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

2013-08-28 Thread Igor Tandetnik

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> SELECT * FROM horde_alarms WHERE alarm_end < '2013-08-28T23:08:48';
1|2013-08-28 22:00:00

sqlite> SELECT * FROM horde_alarms WHERE alarm_end > '2013-08-28 18:08:48';
1|2013-08-28 22:00:00
--


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, don't mix and match the format with and without T in the middle. 
Choose one, and stick to it.

--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


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

2013-08-28 Thread Thomas Jarosch
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 horde_alarms WHERE alarm_end < '2013-08-28T23:08:48';
1|2013-08-28 22:00:00

sqlite> SELECT * FROM horde_alarms WHERE alarm_end > '2013-08-28 18:08:48';
1|2013-08-28 22:00:00
--


This query does not work (as used by Horde):
--
SELECT * FROM horde_alarms WHERE alarm_end > '2013-08-28T18:08:48';
--

Looks like the handling of ISO-8601 date strings has a problem here.
Tested on sqlite 3.7.17. Version 3.6.x is also affected.

Best regards,
Thomas
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Path Length Limit on Windows

2013-08-28 Thread Richard Hipp
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 new windows VFS module called
"win32-longpath" which accepts the full-length 32KB pathnames.  Add the
string "win32-longpath" as the 4th argument to sqlite3_open_v2() (on
windows only, of course) and everything should just work after that.


-- 
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] Different result from experimental query

2013-08-28 Thread Richard Hipp
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

2013-08-28 Thread Misty De Meo
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 64-bit systems.

The attached patch for this issue is based on a similar solution adopted by
fontconfig:
http://cgit.freedesktop.org/fontconfig/commit/?id=0f9aa8759df563332db60055ae33dd9424ebf802It
defines a macro for the function, which calls
OSAtomicCompareAndSwapPtrBarrier() if available and otherwise calls
OSAtomicCompareAndSwap32Barrier() or OSAtomicCompareAndSwap64Barrier() as
appropriate. The patch contains an explanatory comment, but still uses
fontconfig's macro name, which I can change if you rather.

Thanks,
Misty De Meo

--- sqlite3.c.orig2013-08-27 18:37:13.0 -0700
+++ sqlite3.c2013-08-27 21:25:45.0 -0700
@@ -15685,6 +15685,7 @@
 #include 
 #include 
 #include 
+
 static malloc_zone_t* _sqliteZone_;
 #define SQLITE_MALLOC(x) malloc_zone_malloc(_sqliteZone_, (x))
 #define SQLITE_FREE(x) malloc_zone_free(_sqliteZone_, (x));
@@ -15692,6 +15693,29 @@
 #define SQLITE_MALLOCSIZE(x) \
 (_sqliteZone_ ? _sqliteZone_->size(_sqliteZone_,x) :
malloc_size(x))

+/*
+** If compiling for Mac OS X 10.4, the OSAtomicCompareAndSwapPtrBarrier
+** function will not be available, but individual 32-bit and 64-bit
+** versions will.
+*/
+
+#ifdef __MAC_OS_X_MIN_REQUIRED
+# include 
+#elif defined(__IPHONE_OS_MIN_REQUIRED)
+# include 
+#endif
+
+typedef int fc_atomic_int_t;
+#if (MAC_OS_X_VERSION_MIN_REQUIRED > MAC_OS_X_VERSION_10_4 ||
__IPHONE_VERSION_MIN_REQUIRED >= 20100)
+# define fc_atomic_ptr_cmpexch(O,N,P) OSAtomicCompareAndSwapPtrBarrier
((void *) (O), (void *) (N), (void **) (P))
+#else
+# if __ppc64__ || __x86_64__
+#  define fc_atomic_ptr_cmpexch(O,N,P) OSAtomicCompareAndSwap64Barrier
((int64_t) (O), (int64_t) (N), (int64_t*) (P))
+# else
+#  define fc_atomic_ptr_cmpexch(O,N,P) OSAtomicCompareAndSwap32Barrier
((int32_t) (O), (int32_t) (N), (int32_t*) (P))
+# endif
+#endif
+
 #else /* if not __APPLE__ */

 /*
@@ -15852,7 +15876,7 @@
 malloc_zone_t* newzone = malloc_create_zone(4096, 0);
 malloc_set_zone_name(newzone, "Sqlite_Heap");
 do{
-  success = OSAtomicCompareAndSwapPtrBarrier(NULL, newzone,
+  success = fc_atomic_ptr_cmpexch(NULL, newzone,
  (void * volatile *)&_sqliteZone_);
 }while(!_sqliteZone_);
 if( !success ){
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Different result from experimental query

2013-08-28 Thread Richard Hipp
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 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.
> Below is a simplified case. This is still complex but if you leave out
> anything further, the problem no longer occurs. Hope it is useful to report
> this.
>
> .echo on
> .version
> SQLite 3.8.0 2013-08-26 04:50:08 f64cd21e2e23ed7cff48f7dafa5e76**
> adde9321c2
> CREATE TABLE t (id INTEGER PRIMARY KEY NOT NULL)
> ;
> INSERT INTO t VALUES (1)
> ;
> SELECT  *
> FROMt t1
> LEFT OUTER JOIN t t2 ON t2.id BETWEEN 10 AND 20
> JOINt t3 ON
> (
> t3.id = t1.id
> OR  t2.id IS NOT NULL AND t3.id = t2.id
> )
> ;
>
> -- E Pasma
> __**_
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users
>



-- 
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] Different result from experimental query

2013-08-28 Thread pasma10
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 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-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org]
> On Behalf Of E.Pasma
> Sent: Wednesday, August 28, 2013 10:20 AM
> To: General Discussion of SQLite Database
> Subject: [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.
> Below is a simplified case. This is still complex but if you leave out
> anything further, the problem no longer occurs. Hope it is useful to report
> this.
> 
> .echo on
> .version
> SQLite 3.8.0 2013-08-26 04:50:08
> f64cd21e2e23ed7cff48f7dafa5e76adde9321c2
> CREATE TABLE t (id INTEGER PRIMARY KEY NOT NULL) ; INSERT INTO t VALUES (1) ;
> SELECT  *
> FROMt t1
> LEFT OUTER JOIN t t2 ON t2.id BETWEEN 10 AND 20
> JOINt t3 ON
> (
> t3.id = t1.id
> OR  t2.id IS NOT NULL AND t3.id = t2.id
> )
> ;
> 
> -- E Pasma
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> 
> 
> This email and any attachments are only for use by the intended recipient(s)
> and may contain legally privileged, confidential, proprietary or otherwise
> private information. Any unauthorized use, reproduction, dissemination,
> distribution or other disclosure of the contents of this e-mail or its
> attachments is strictly prohibited. If you have received this email in error,
> please notify the sender immediately and delete the original.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Different result from experimental query

2013-08-28 Thread Marc L. Allen
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-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] 
On Behalf Of E.Pasma
Sent: Wednesday, August 28, 2013 10:20 AM
To: General Discussion of SQLite Database
Subject: [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.
Below is a simplified case. This is still complex but if you leave out anything 
further, the problem no longer occurs. Hope it is useful to report this.

.echo on
.version
SQLite 3.8.0 2013-08-26 04:50:08
f64cd21e2e23ed7cff48f7dafa5e76adde9321c2
CREATE TABLE t (id INTEGER PRIMARY KEY NOT NULL) ; INSERT INTO t VALUES (1) ; 
SELECT  *
FROMt t1
LEFT OUTER JOIN t t2 ON t2.id BETWEEN 10 AND 20
JOINt t3 ON
 (
 t3.id = t1.id
 OR  t2.id IS NOT NULL AND t3.id = t2.id
 )
;

-- E Pasma
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


This email and any attachments are only for use by the intended recipient(s) 
and may contain legally privileged, confidential, proprietary or otherwise 
private information. Any unauthorized use, reproduction, dissemination, 
distribution or other disclosure of the contents of this e-mail or its 
attachments is strictly prohibited. If you have received this email in error, 
please notify the sender immediately and delete the original.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


[sqlite] Different result from experimental query

2013-08-28 Thread E.Pasma
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.
Below is a simplified case. This is still complex but if you leave out  
anything further, the problem no longer occurs. Hope it is useful to  
report this.


.echo on
.version
SQLite 3.8.0 2013-08-26 04:50:08  
f64cd21e2e23ed7cff48f7dafa5e76adde9321c2

CREATE TABLE t (id INTEGER PRIMARY KEY NOT NULL)
;
INSERT INTO t VALUES (1)
;
SELECT  *
FROMt t1
LEFT OUTER JOIN t t2 ON t2.id BETWEEN 10 AND 20
JOINt t3 ON
(
t3.id = t1.id
OR  t2.id IS NOT NULL AND t3.id = t2.id
)
;

-- E Pasma
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] 3.8.0 Update

2013-08-28 Thread James Pearson

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 and seem to have lost the 
ability to use

the up arrow key to cycle through my command line history.


Which OS?

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

- - -

Mac OS X - 10.8.4


Updated by building the sqlite-autoconf-308.tar.gz
package, correct?

Are you upgrading from an earlier version that you had
built and installed yourself? Or from the system SQLite?

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


- - -

Actually I updated from the precompiled Mac binaries, and my previous 
version was also from the precompiled binaries.


I've never built SQLite myself.


- - -

Do I need to build SQLite from source to turn the command history back 
on?


If so what options/libraries/etc do I need to use to do so?

Thanks
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


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

2013-08-28 Thread Max Vlasov
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
> to mean the table column or the alias.

Thanks, Igor, sorry, didn't notice the original discussion

Max
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] v3.8 .import misbehaves

2013-08-28 Thread Simon Slavin

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). [snip]
> 
> Agreed.
> The CR character seems not to be handled properly. Change CRLF to just
> LF, and the import succeeds. Change CRLF to CR and same failure as
> above.

Nice diagnosis.  Well done.

Technically, all CSV lines except the last should be delimited by CRLF, and the 
last line does not need (but may have) the CRLF.  RFC4180 2.1 and 2.2:

1.  Each record is located on a separate line, delimited by a line break (CRLF).
2.  The last record in the file may or may not have an ending line break.

In practise, most CSV importing software does something like

1. Convert all LF to CR.
2. Convert all CRCR to CR
3. Read data as lines delimited by CR
4. Ignore all lines which are entirely blank

so it doesn't matter.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] v3.8 .import misbehaves

2013-08-28 Thread Richard Hipp
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

2013-08-28 Thread Simon Davies
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"
> "1833","","49.3275923134","","118.3483703666","","",""
> "1833","","49.3275923134","","118.3483703666","","",""
> "1833","","49.3275923134","","118.3483703666","","",""
> "1833","","49.3275923134","","118.3483703666","","",""
> "1833","","49.3275923134","","118.3483703666","","",""
> "1833","","49.3275923134","","118.3483703666","","",""
> ---
>
> 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
> data:3: unescaped " character
> data:4: unescaped " character
> data:5: unescaped " character
> data:6: unescaped " character
> data:7: unescaped " character
> data:2: expected 8 columns but found 43 - extras ignored
> sqlite>
>

Agreed.
The CR character seems not to be handled properly. Change CRLF to just
LF, and the import succeeds. Change CRLF to CR and same failure as
above.

Regards,
Simon
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] v3.8 .import misbehaves

2013-08-28 Thread tonyp

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 of SQLite Database 
Subject: 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","","",""
"1833","","49.3275923134","","118.3483703666","","",""
"1833","","49.3275923134","","118.3483703666","","",""
"1833","","49.3275923134","","118.3483703666","","",""
"1833","","49.3275923134","","118.3483703666","","",""
"1833","","49.3275923134","","118.3483703666","","",""
---

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
data:3: unescaped " character
data:4: unescaped " character
data:5: unescaped " character
data:6: unescaped " character
data:7: unescaped " character
data:2: expected 8 columns but found 43 - extras ignored
sqlite>

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] v3.8 .import misbehaves

2013-08-28 Thread tonyp
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","","",""
"1833","","49.3275923134","","118.3483703666","","",""
"1833","","49.3275923134","","118.3483703666","","",""
"1833","","49.3275923134","","118.3483703666","","",""
"1833","","49.3275923134","","118.3483703666","","",""
"1833","","49.3275923134","","118.3483703666","","",""
---

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
data:3: unescaped " character
data:4: unescaped " character
data:5: unescaped " character
data:6: unescaped " character
data:7: unescaped " character
data:2: expected 8 columns but found 43 - extras ignored
sqlite>

-Original Message- 
From: Simon Davies

Sent: Wednesday, August 28, 2013 4:06 PM
To: General Discussion of SQLite Database
Subject: 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 terminated with a ";"
sqlite> .sep ,
sqlite> .import data tab
data:2: unterminated "-quoted field
sqlite>





I can confirm the behaviour with
C:\>xd -c data.txt
0: 22 59 65 61 72 22 2C 22  44 65 62 74 22 2C 22 47 | "Year","Debt","G
   10: 44 50 31 22 2C 22 47 44  50 32 22 2C 22 52 47 44 | DP1","GDP2","RGD
   20: 50 22 2C 22 64 52 47 44  50 22 2C 22 49 6E 66 6C | P","dRGDP","Infl
   30: 22 2C 22 64 65 62 74 67  64 70 22 0D 0A 22 31 38 | ","debtgdp".."18
   40: 33 33 22 2C 22 22 2C 22  34 39 2E 33 32 37 35 39 | 33","","49.32759
   50: 32 33 31 33 34 22 2C 22  22 2C 22 31 31 38 2E 33 | 23134","","118.3
   60: 34 38 33 37 30 33 36 36  36 22 2C 22 22 2C 22 22 | 483703666","",""
   70: 2C 22 22 0D 0A   | ,""..
C:> sqlite3
SQLite version 3.8.0 2013-08-26 04:50:08
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .sep ,
sqlite>
sqlite> .import data.txt tab
data.txt:2: unterminated "-quoted field

But change file to:

C:\Joinerysoft\Software\sqlite\3_8_0>xd -c data.txt
0: 22 59 65 61 72 22 2C 22  44 65 62 74 22 2C 22 47 | "Year","Debt","G
   10: 44 50 31 22 2C 22 47 44  50 32 22 2C 22 52 47 44 | DP1","GDP2","RGD
   20: 50 22 2C 22 64 52 47 44  50 22 2C 22 49 6E 66 6C | P","dRGDP","Infl
   30: 22 2C 22 64 65 62 74 67  64 70 22 0D 0A 22 31 38 | ","debtgdp".."18
   40: 33 33 22 2C 22 22 2C 22  34 39 2E 33 32 37 35 39 | 33","","49.32759
   50: 32 33 31 33 34 22 2C 22  22 2C 22 31 31 38 2E 33 | 23134","","118.3
   60: 34 38 33 37 30 33 36 36  36 22 2C 22 22 2C 22 22 | 483703666","",""
   70: 2C 22 22 | ,""

(remove trailing newline) and the import works with no errors.

Regards,
Simon
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users 


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


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

2013-08-28 Thread Igor Tandetnik

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 ('simple text ');
select Trim(Title) as Title, Count(*) as Cnt FROM TestTable Group By Title;

produces two results

"simple text""2"
"simple text""1"

while all previous versions I tried a single one

"simple text""3"


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 to mean the table column or the alias. The correct behavior is 
that exhibited by 3.8, and apparently by 3.7.15 and earlier: GROUP BY 
should prefer the table column over the alias. There were a couple of 
releases in between that behaved differently.

--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] v3.8 .import misbehaves

2013-08-28 Thread Simon Davies
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 terminated with a ";"
> sqlite> .sep ,
> sqlite> .import data tab
> data:2: unterminated "-quoted field
> sqlite>
>
>


I can confirm the behaviour with
C:\>xd -c data.txt
 0: 22 59 65 61 72 22 2C 22  44 65 62 74 22 2C 22 47 | "Year","Debt","G
10: 44 50 31 22 2C 22 47 44  50 32 22 2C 22 52 47 44 | DP1","GDP2","RGD
20: 50 22 2C 22 64 52 47 44  50 22 2C 22 49 6E 66 6C | P","dRGDP","Infl
30: 22 2C 22 64 65 62 74 67  64 70 22 0D 0A 22 31 38 | ","debtgdp".."18
40: 33 33 22 2C 22 22 2C 22  34 39 2E 33 32 37 35 39 | 33","","49.32759
50: 32 33 31 33 34 22 2C 22  22 2C 22 31 31 38 2E 33 | 23134","","118.3
60: 34 38 33 37 30 33 36 36  36 22 2C 22 22 2C 22 22 | 483703666","",""
70: 2C 22 22 0D 0A   | ,""..
C:> sqlite3
SQLite version 3.8.0 2013-08-26 04:50:08
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .sep ,
sqlite>
sqlite> .import data.txt tab
data.txt:2: unterminated "-quoted field

But change file to:

C:\Joinerysoft\Software\sqlite\3_8_0>xd -c data.txt
 0: 22 59 65 61 72 22 2C 22  44 65 62 74 22 2C 22 47 | "Year","Debt","G
10: 44 50 31 22 2C 22 47 44  50 32 22 2C 22 52 47 44 | DP1","GDP2","RGD
20: 50 22 2C 22 64 52 47 44  50 22 2C 22 49 6E 66 6C | P","dRGDP","Infl
30: 22 2C 22 64 65 62 74 67  64 70 22 0D 0A 22 31 38 | ","debtgdp".."18
40: 33 33 22 2C 22 22 2C 22  34 39 2E 33 32 37 35 39 | 33","","49.32759
50: 32 33 31 33 34 22 2C 22  22 2C 22 31 31 38 2E 33 | 23134","","118.3
60: 34 38 33 37 30 33 36 36  36 22 2C 22 22 2C 22 22 | 483703666","",""
70: 2C 22 22 | ,""

(remove trailing newline) and the import works with no errors.

Regards,
Simon
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


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

2013-08-28 Thread John McKown
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 ('simple text');
> INsert into TestTable (Title) VALUES ('simple text');
> INsert into TestTable (Title) VALUES ('simple text ');
> select Trim(Title) as Title, Count(*) as Cnt FROM TestTable Group By Title;
>
> produces two results
>
> "simple text""2"
> "simple text""1"
>
> while all previous versions I tried a single one
>
> "simple text""3"
>
> Speaking about the correct way, seems like 3.8 is right (technically
> the strings are different), but I just wonder why all this time this
> seems like existed and never noticed. On the other side, mysql of a
> some old version also showed a single result
>
> Max
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
As of next week, passwords will be entered in Morse code.

Maranatha! <><
John McKown
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


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

2013-08-28 Thread Max Vlasov
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) as Title, Count(*) as Cnt FROM TestTable Group By Title;

produces two results

"simple text""2"
"simple text""1"

while all previous versions I tried a single one

"simple text""3"

Speaking about the correct way, seems like 3.8 is right (technically
the strings are different), but I just wonder why all this time this
seems like existed and never noticed. On the other side, mysql of a
some old version also showed a single result

Max
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] v3.8 .import misbehaves

2013-08-28 Thread tonyp
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
data:2: unterminated "-quoted field
sqlite>

-Original Message- 
From: Richard Hipp

Sent: Wednesday, August 28, 2013 3:47 PM
To: General Discussion of SQLite Database
Subject: 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"
"1833","","49.3275923134","","**118.3483703666","","",""

Then, doing
.sep ,
.import data tab

gives error(s).



Unable to reproduce the problem.  The example above works correctly for me
using SQLite 3.8.0 on Linux and on Windows8.

Please verify that you are using 3.8.0 (where this problem has been fixed)
and not SQLite version 3.7.17 or earlier.

--
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-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] v3.8 .import misbehaves

2013-08-28 Thread Simon Slavin

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 things.  You might want to use hexdump to dump 
your file and make sure it doesn't have control characters in it.

> Another less important issue, I think it should put NULLs instead of blanks 
> for blank columns.

It would be correct to insert NULLs for this line

> "1833",,"49.3275923134",,"118.3483703666",,,

But this line explicitly states that there are zero-length strings:

> "1833","","49.3275923134","","118.3483703666","","",""

And the example I gave for NULLs arguably does not conform to CSV format.  
Handling it properly might do no harm, though.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] v3.8 .import misbehaves

2013-08-28 Thread Richard Hipp
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"
> "1833","","49.3275923134","","**118.3483703666","","",""
>
> Then, doing
> .sep ,
> .import data tab
>
> gives error(s).
>

Unable to reproduce the problem.  The example above works correctly for me
using SQLite 3.8.0 on Linux and on Windows8.

Please verify that you are using 3.8.0 (where this problem has been fixed)
and not SQLite version 3.7.17 or earlier.

-- 
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

2013-08-28 Thread tonyp
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 error(s).

Replacing double quotes with blanks lets it work.  (Running on Win7, if it 
matters.)


Another less important issue, I think it should put NULLs instead of blanks 
for blank columns.


-Original Message- 
From: Richard Hipp

Sent: Wednesday, August 28, 2013 2:58 PM
To: General Discussion of SQLite Database
Subject: 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 found inside a string.
 The leading quote should not be considered an escaped quote.  The ,"",
pattern is very common for denoting empty field.



Unable to reproduce the problem.  CSV import works according to RFC4180
when I try it.

--
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-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] CREATE INDEX and column order

2013-08-28 Thread Richard Hipp
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 clause as a set.

-- 
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] CREATE INDEX and column order

2013-08-28 Thread Doug Nebeker
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 [mailto:sqlite-users-boun...@sqlite.org] 
On Behalf Of Simon Slavin
Sent: Tuesday, August 27, 2013 7:29 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] CREATE INDEX and column order


On 27 Aug 2013, at 1:07pm, Doug Nebeker  wrote:

> I was reading about the new query planner and came across a few references to 
> that idea that the left most columns in the index definition should be the 
> most unique (as far as values in the column are concerned).
> 
> Is that correct?  In my case, many tables have a timestamp column, and I've 
> been using that as my right-most column, but it seems it would be a great 
> candidate to be switched.

When using an index, SQL has to work from the most significant end -- the left 
-- to the least significant end -- the right.  For instance, suppose you have a 
phone book

CREATE TABLE phonebook (firstname TEXT, surname TEXT, phonenumber TEXT) CREATE 
INDEX psf ON phonebook (surname, firstname)

This index is useless for looking someone up by their firstname, because it has 
everyone listed in surname order:

Abelson, David
Abelson, Joan
Smith, David
Smith, Martine
Smith, Tom

If you wanted to look up all the 'Martines' you'd just have to look through the 
whole index anyway.  You might as well scan the original table. [1]

Simon.

[1] Yes, many picky details about this but I'm simplifying for the purpose of 
explanation.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] v3.8 .import misbehaves

2013-08-28 Thread Richard Hipp
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 found inside a string.
>  The leading quote should not be considered an escaped quote.  The ,"",
> pattern is very common for denoting empty field.
>

Unable to reproduce the problem.  CSV import works according to RFC4180
when I try it.

-- 
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] v3.8 .import misbehaves

2013-08-28 Thread tonyp
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 considered an escaped quote.  The ,"", pattern 
is very common for denoting empty field. 


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] BETWEEN and explicit collation assignment

2013-08-28 Thread Konrad Hambrick
> -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 Aug 2013 19:03:39 +
> Roman Fleysher  wrote:
> 
> > However, sometimes, in comparison we want to ignore some of the
> > attributes, or compare derived ones. Many busses can carry 25 people,
> > and may be considered equal if we simply need to transport people.
> > Busses certainly differ by other attributes.
> 
> Busses might indeed differ in many ways, but if you make NAME the
> primary key for BUSSES, the rule is not "compare BUSSES, ignoring
> columns other than NAME".  The rule is "compare BUSSES.NAME".
> 
> > it is the comparison ( "=", BETWEEN, IN , etc) statements that must
> > be modified
> 
> This not a syntax issue.  Equality is deeply embedded in the system, in
> many places where there's no SQL in play (e.g. keys).
> 
> It's a system of types and operators.  We can already convert between
> types and compare them.  If you can show some kind of comparison
> that *cannot* be done via type conversion using the operators exactly
> as they are, you might have a point.
> 

Roman --

Another issue is the fundamental but often confused difference between 
Object Oriented Programming and Relational DataBases ( AKA the Object
Relational Impedance mismatch ) 

One should not model a complex object like a Bus in a Relational DB as 
an amorphous Blob, it should instead be modeled as as a collection of 
orthogonal attributes in a set of atomic columns, each having a specific 
type in one-or-more tables.

Equality, or more generally, comparison of the column primitives is 
absolutely as James said, 'deeply embedded in the system itself'.

Be the CPU ...

To find the Bus that fits your needs, you would need to compare sets 
of primitive Attributes of interest to specific needs, invoking AND-OR 
clauses to combine those specific primitive comparisons.

For example:  to find the Name of all the short busses:

   -- one model of a bus might be:

   CREATE TABLE Bus
   (
  IdIntINTEGER PRIMARY KEY AUTOINCREMENT
, Name  varchar( 32 )  COLLATE NOCASE
, Color varchar( 16 )  COLLATE NOCASE
, Lengthnumeric( 5,3 )
, Capacity  int  
   ) 
   ;

   -- find the Name of each short bus:

   SELECT Name 
 FROM Bus
WHEREColor = 'yellow'
  AND (( Length < 20 ) 
  OR   ( Capacity >= 8 AND Capacity < 16 ))  
   ;
 
-- kjh


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Database locking Error

2013-08-28 Thread Simon Slavin

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.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] I/O error in sqlite3

2013-08-28 Thread techi eth
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 application is working fine.
>
> In above case what is the system architecture requirement to get WAL mode
> enable?
>
> How do I can achieve better concurrency in terms of reading?
>
> Thanks.
>
>
> On Tue, Aug 27, 2013 at 9:58 AM, techi eth  wrote:
>
>> What is possible cause of I/O error in sqlite3?
>>
>> My application is running fine on Desktop PC.Same application when I try
>> to run on ARM target it is giving I/O error.
>>
>> sqlite3 on Host : 3.7.9
>>
>> sqlite3 on Target : 3.7.14.1
>>
>
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Database locking Error

2013-08-28 Thread techi eth
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 _exec().
> >
> > Do you see any issue ?
>
> Nothing obvious from what I already know apart from the fact that you
> don't mention setting a timeout:
>
> 
> 
>
> Without that, a process getting a lock won't back off and retry, it'll
> just immediately return an error.  Which is almost never what people want.
>  You would probably be better off setting this to 5 seconds or something.
>
> I suspect that the process which is getting the lock is fine and that it's
> the other process which is keeping the file locked.
>
> Are you checking the return codes from /all/ your SQLite calls in other
> processes ?  The code you included doesn't seem to do that but I thought
> that might be pseudocode.
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users