Re: [sqlite] Does using e.g. LTRIM function remove collation?

On Thu, 6 Nov 2014 17:02:26 -0500 Richard Hipp wrote: > > sqlite> INSERT INTO test VALUES ('b'), ('A'), ('B'), ('a'); > > sqlite> SELECT * FROM test; > > b > > A > > B > > a ... > > sqlite> SELECT * FROM test WHERE LTRIM(col)<'b'; > > A > > B > > A ... > Works as designed. See

Re: [sqlite] Is it safe to use backup at shell level when an application is running

On 7 Nov 2014, at 10:33am, Yves Crespin wrote: > We use sqlite3_open_v2() with > SQLITE_OPEN_READWRITE|SQLITE_OPEN_FULLMUTEX flags and all the > transactions are exclusive. > > > So, if we add a SQLITE_BUSY handle, can we use the sqlite3 .backup > when the

Re: [sqlite] Is it safe to use backup at shell level when an application is running

Great ! Thanks a lot regards, yves yves crespin t. +33.(0)6.86.42.86.81 yvescrespin 2014-11-07 12:21 GMT+01:00 Clemens Ladisch : > Yves Crespin wrote: >> if we add a SQLITE_BUSY handle, can we use the sqlite3 .backup when >> [some] application is running? >> >> Is it safe

Re: [sqlite] Bug report: typo in sqlite3.h

On 7 Nov 2014, at 9:18am, Philip Newton wrote: > The amalgamation-3080701 sqlite3.h file has a comment that reads, in part: > > ** These no-op macros are used in front of interfaces to mark those > ** interfaces as either deprecated or experimental. New applications >

Re: [sqlite] AUTOINCREMENT BIGINT

Ok understand thanks Il 07/11/2014 14.40, Richard Hipp ha scritto: On Fri, Nov 7, 2014 at 8:26 AM, Michele Pradella

Re: [sqlite] sqlite - 64bit support

On Fri, Nov 7, 2014 at 5:44 AM, Vadiraj V wrote: > I would like to know if sqlite supports 64-bit - if so, from which version > it supports and any supporting documentation exists. Thanks. > All versions of SQLite going back to 3.0.0 support 64-bit. -- D. Richard

Re: [sqlite] AUTOINCREMENT BIGINT

On Fri, Nov 7, 2014 at 8:26 AM, Michele Pradella wrote: > > Is there a way to sue AUTOINCREMENT with BIGINT? what's the reason for > this check? > No. Furthermore, AUTOINCREMENT probably does not do what you think it does. Please read the details at

Re: [sqlite] AUTOINCREMENT BIGINT

Michele Pradella wrote: > I have a question about data type BIGINT BIGINT is not a data type. > from docs (http://www.sqlite.org/datatype3.html) This page says the data types are NULL, INTEGER, REAL, TEXT, and BLOB. > I understand that INTEGER and BIGINT results in the same affinity Yes. >

[sqlite] AUTOINCREMENT BIGINT

Hi all, I have a question about data type BIGINT: from docs (http://www.sqlite.org/datatype3.html) I understand that INTEGER and BIGINT results in the same affinity (INTEGER), so datatypes are same, is it correct? Unfortunately if I create a table with a field "Id BIGINT PRIMARY KEY

[sqlite] sqlite - 64bit support

I would like to know if sqlite supports 64-bit - if so, from which version it supports and any supporting documentation exists. Thanks. Regards, Vadiraj. ___ sqlite-users mailing list sqlite-users@sqlite.org

[sqlite] Bug report: typo in vacuum.c

In amalgamation-3080701 in sqlite3.c, in a section apparently originally from vacuum.c, there is a comment that reads in part: ** Only 1x temporary space and only 1x writes would be required if ** the copy of step (3) were replace by deleting the original database ** and renaming the transient

[sqlite] Bug report: Inconsistent usage of "[Jj]ulian [Dd]ay ([Nn]umbers)" in date.c

In the sqlite-amalgamation-3080701, in included file "date.c", the comments refer, at various times, to: - julian day, julian day number, julian day numbers - Julian day number - Julian Day numbers - Julian Day Number These should probably be unified in terms of capitalisation. Also, there is a

[sqlite] Bug report: typo in sqlite3.c (global.c)

The amalgamation-3080701 contains in sqlite3.c a comment that reads in part: ** IMPORTANT: Changing the pending byte to any value other than ** 0x4000 results in an incompatible database file format! ** Changing the pending byte during operating results in undefined ** and dileterious

[sqlite] Bug report: typo in website

http://www.sqlite.org/amalgamation.html says: "The sqlite3.h file is also contained within the amalgamation, in the first few of thousand lines." I'm guessing that used to read "the first couple of thousand lines". But with "few", the "of" is wrong; it should read "the first few thousand

Re: [sqlite] Is it safe to use backup at shell level when an application is running

Yves Crespin wrote: > if we add a SQLITE_BUSY handle, can we use the sqlite3 .backup when > [some] application is running? > > Is it safe or is there a risk to corrumpt the database or do we need > to change some settings ? Using the backup API is perfectly safe for your data. The only risk is

[sqlite] Is it safe to use backup at shell level when an application is running

Hi, We use SQLite3 in a multi-threaded application. Now we must provide a 24/7 service and we don't want to change this legacy application. We use sqlite3_open_v2() with SQLITE_OPEN_READWRITE|SQLITE_OPEN_FULLMUTEX flags and all the transactions are exclusive. So, if we add a SQLITE_BUSY

[sqlite] Bug report: typo in sqlite3.h

The amalgamation-3080701 sqlite3.h file has a comment that reads, in part: ** These no-op macros are used in front of interfaces to mark those ** interfaces as either deprecated or experimental. New applications ** should not use deprecated interfaces - they are support for backwards **