Re: [sqlite] Curious datetime/strftime BUG?

John wrote: > -4713-11-25 12:00:00<-- 4 digit year > -471-11-25 12:00:00 <-- 3 digit year > -001-12-31 <-- 3 digit year > -001-12-31 <-- 3 digit year > -1975-10-21<-- 4 digit year > -197-10-21 <-- 3 digit year The documentation

Re: [sqlite] SELECT ... GROUP BY: Bug or misunderstanding?

Hi Christoph, the id column does not appear in an aggregate function and also not in group by. Your statement uses 'GROUP BY Name' and so returns exactly one row per name. If there are several rows with the same name, the ID of your result is from one of these rows. The appropriate

Re: [sqlite] Sqlite querie delete bug

This doesn't sound like an SQLite problem to me. Instead it sounds like a problem with whatever visualization tool you are using. What tool are you using? If you can find a user's group for that tool, you may get more helpful answers there. RobR -Original Message- From:

Re: [sqlite] Sqlite querie delete bug

On Wed, Jul 30, 2014 at 8:53 AM, Oto _ wrote: > There is an issue that if entry is selected in Table view then editing in > Query view and clicking delete key then it doesn't delete query but asks to > delete database entry which is not expected behavior. > It sounds as if you

Re: [sqlite] sqlite3 shell .import bug (edge case)

Thanks for the test case. Fixed at http://www.sqlite.org/src/info/5e239ecda0 On Wed, Dec 11, 2013 at 6:37 AM, Lindsay Lawrence wrote: > Hi, > > I am currently using sqlite3 version: > > 3.8.1 2013-10-17 12:57:35 c78be6d786c19073b3a6730dfe3fb1be54f5657a > > I found an edge

Re: [sqlite] incredibly minor documentation bug

On Sat, Oct 26, 2013 at 12:30 PM, George Collins wrote: > > "If X is the integer -9223372036854775807 then abs(X) throws an integer > overflow error since there is no equivalent positive 64-bit two complement > value." > > It's off by one: X is actually

Re: [sqlite] Problems (maybe a bug) when creating a backup using the command line interface '.backup' command

On 12/21/2012 05:18 PM, Dan Kennedy wrote: Thanks. I think it's this: http://www.sqlite.org/src/info/0cfd98ee20 Dan. You are right. I have been re-reading our mail thread and this is exactly what happens. I have build a SQLite version from the latest version in the archive (3.7.16) and

Re: [sqlite] Problems (maybe a bug) when creating a backup using the command line interface '.backup' command

On 01/02/2013 11:03 AM, Marco ten Thije wrote: On 01/02/2013 10:04 AM, Dan Kennedy wrote: What series of commands did you pass to 3.7.5 to create this file? This file was copied from an existing product which uses QT 4.7 libraries to populate the database. I cannot reproduce the exact

Re: [sqlite] Problems (maybe a bug) when creating a backup using the command line interface '.backup' command

On 01/02/2013 10:04 AM, Dan Kennedy wrote: What series of commands did you pass to 3.7.5 to create this file? This file was copied from an existing product which uses QT 4.7 libraries to populate the database. I cannot reproduce the exact commands which resulted in this file, because it is

Re: [sqlite] Problems (maybe a bug) when creating a backup using the command line interface '.backup' command

On 01/02/2013 03:27 PM, Marco ten Thije wrote: On 12/21/2012 05:18 PM, Dan Kennedy wrote: Thanks. I think it's this: http://www.sqlite.org/src/info/0cfd98ee20 Dan. Thanks. I have looked into ticket, but we also see this problem when the backup is written and read by the same SQLite version

Re: [sqlite] Problems (maybe a bug) when creating a backup using the command line interface '.backup' command

On 12/21/2012 05:18 PM, Dan Kennedy wrote: Thanks. I think it's this: http://www.sqlite.org/src/info/0cfd98ee20 Dan. Thanks. I have looked into ticket, but we also see this problem when the backup is written and read by the same SQLite version (3.7.5). I have recreated a backup using the

Re: [sqlite] Problems (maybe a bug) when creating a backup using the command line interface '.backup' command

On 12/21/2012 10:54 PM, Marco ten Thije wrote: What is the size of the two database files? The size of both files is 160768 bytes. Also, can we have the first 6 lines of each hex dump (i.e. enough to see the first 100 bytes)? The first bytes of the original database: 000 5153 694c

Re: [sqlite] Problems (maybe a bug) when creating a backup using the command line interface '.backup' command

What is the size of the two database files? The size of both files is 160768 bytes. Also, can we have the first 6 lines of each hex dump (i.e. enough to see the first 100 bytes)? The first bytes of the original database: 000 5153 694c 6574 6620 726f 616d 2074 0033 010 0004 0101

Re: [sqlite] Problems (maybe a bug) when creating a backup using the command line interface '.backup' command

On 12/21/2012 08:46 PM, Marco ten Thije wrote: It returns 'ok': ./sqlite3 energy.sqlite SQLite version 3.7.15.1 2012-12-19 20:39:10 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> pragma integrity_check; ok sqlite> So, the original database looks ok. I have

Re: [sqlite] Problems (maybe a bug) when creating a backup using the command line interface '.backup' command

It returns 'ok': ./sqlite3 energy.sqlite SQLite version 3.7.15.1 2012-12-19 20:39:10 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> pragma integrity_check; ok sqlite> So, the original database looks ok. I have compared the two databases (original and backup)

Re: [sqlite] Problems (maybe a bug) when creating a backup using the command line interface '.backup' command

Can you please try running "pragma integrity_check;" on the original database? That will give an indication of whether the original database has any data corruption. On Fri, Dec 21, 2012 at 4:13 AM, Marco ten Thije < marco.tenth...@usetechnology.nl> wrote: > Hello, > > We are facing a problem

Re: [sqlite] SQLite4 key encoding bug

On Tue, Jul 10, 2012 at 11:54 AM, Igor Tandetnik wrote: > On 7/10/2012 11:44 AM, Richard Hipp wrote: > >> SQLite4 is still using "double" internally for floating point >> computations. (Yes, there are plans to change that but it has not >> happened >> yet.) The bug above is

Re: [sqlite] SQLite4 key encoding bug

On 7/10/2012 11:44 AM, Richard Hipp wrote: SQLite4 is still using "double" internally for floating point computations. (Yes, there are plans to change that but it has not happened yet.) The bug above is due to rounding errors in the doubles, specifically rounding errors that occur when doing

Re: [sqlite] SQLite4 key encoding bug

On Tue, Jul 10, 2012 at 11:33 AM, Igor Tandetnik wrote: > On 7/10/2012 11:24 AM, Ryan Johnson wrote: > >> On 10/07/2012 9:58 AM, >> bardzotajneko...@interia.pl wrote: >> >>> SQLite version 4.0.0 2012-07-07 12:21:48 >>> Enter ".help" for instructions >>> Enter SQL statements

Re: [sqlite] SQLite4 key encoding bug

On 7/10/2012 11:24 AM, Ryan Johnson wrote: On 10/07/2012 9:58 AM, bardzotajneko...@interia.pl wrote: SQLite version 4.0.0 2012-07-07 12:21:48 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> create table t(a); sqlite> insert into t values(123); sqlite> insert

Re: [sqlite] SQLite4 key encoding bug

On 10/07/2012 9:58 AM, bardzotajneko...@interia.pl wrote: SQLite version 4.0.0 2012-07-07 12:21:48 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> create table t(a); sqlite> insert into t values(123); sqlite> insert into t values(123.0); sqlite> insert into t

Re: [sqlite] [shell] utf-8 bug

Thank you! What a mess... On Tue, Dec 27, 2011 at 9:00 PM, Kevin Benson wrote: > On 12/27/11, Jens Frederich wrote: > > The sqlite3 command line app doesn't write the string correctly to the > > database file. It uses the terminal (cmd) encoding

Re: [sqlite] [shell] utf-8 bug

On 12/27/11, Jens Frederich wrote: > The sqlite3 command line app doesn't write the string correctly to the > database file. It uses the terminal (cmd) encoding instead the 'PRAGMA > encoding' statement. chcp 65001 ...may not be a reliable avenue:

Re: [sqlite] [shell] utf-8 bug

On Tue, Dec 27, 2011 at 12:44 PM, Jens Frederich wrote: > The sqlite3 command line app doesn't write the string correctly to the > database file. It uses the terminal (cmd) encoding instead the 'PRAGMA > encoding' statement. None of the SQLite3 code converts between

Re: [sqlite] [shell] utf-8 bug

I'm an UTF-8 expert. Code page 65001 is CP_UTF8, look here ( http://msdn.microsoft.com/en-us/library/windows/desktop/ms683169(v=vs.85).aspx ). I know that code page 437 (alias OEM) works. But the ü-character isn't correct encoded in the database file. The UTF-8 hex byte sequence of ü is

Re: [sqlite] [shell] utf-8 bug

I"m not a UTF expert but codepage 437 seems to work fine for your example. codepage 65001 is not "real" UTF-8 according to several google sources. You do have to use Lucida font. C:\chcp 437 Active code page: 437 C:\sqlite test.db SQLite version 3.7.9 2011-11-01 00:52:41 Enter ".help"

Re: [sqlite] Unexplained minor regression (bug) 3.7.8 up

On Wed, Dec 7, 2011 at 2:48 AM, Max Vlasov wrote: > > btw, could not find exact steps for getting trunk amalgamation. > Is it : > - get > http://www.sqlite.org/src/tarball/sqlite-latest-trunk.tar.gz?uuid=trunk > - extract on a unix-compatible machine > - ./configure > -

Re: [sqlite] Unexplained minor regression (bug) 3.7.8 up

On Tue, Dec 6, 2011 at 9:49 PM, Dan Kennedy wrote: > On 12/06/2011 03:28 PM, Max Vlasov wrote: > >> Hi, >> Noticed a strange regression after 3.7.7 (in 3.7.8 and inherited in 3.7.9) >> >> > There is a candidate fix for this in fossil now. > > Dan, thanks I checked the

Re: [sqlite] Unexplained minor regression (bug) 3.7.8 up

On 12/06/2011 03:28 PM, Max Vlasov wrote: Hi, Noticed a strange regression after 3.7.7 (in 3.7.8 and inherited in 3.7.9) I have a Russian morphology database and different queries working with it. I narrowed it to the following case and populated with a couple of English words (just to make

Re: [sqlite] Is this a bug? Can't tell from docs....

On Fri, Nov 18, 2011 at 05:30:20PM -0800, Yang Zhang scratched on the wall: > I just got bit by some peculiar behavior in sqlite where > >  id int primary key > is different from: >  id integer primary key > In particular, sqlite will generate values for the latter but not the former: Well,

Re: [sqlite] Is this a bug? Can't tell from docs....

Actually, it is documented, on the CREATE TABLE page, near the bottom, in the section titled "ROWIDs and the INTEGER PRIMARY KEY". Not that this is an exactly obvious place to look for it... Best regards, Peter > -Original Message- > From: sqlite-users-boun...@sqlite.org

Re: [sqlite] [patch] Re: Potential bug: "insert into X select * from Y" ignores the "ON CONFLICT REPLACE" conflict-clause

Yuriy Kaminskiy wrote: > Yuriy Kaminskiy wrote: >> David wrote: >>> Simon L wrote 2011-10-25 06:20: To reproduce this problem, enter the following 5 SQL statements at the SQLite command line. create table X(id INTEGER primary key ON CONFLICT REPLACE); create table Y(id

Re: [sqlite] [patch] Re: Potential bug: "insert into X select * from Y" ignores the "ON CONFLICT REPLACE" conflict-clause

Yuriy Kaminskiy wrote: > David wrote: >> Simon L wrote 2011-10-25 06:20: >>> To reproduce this problem, enter the following 5 SQL statements at the >>> SQLite command line. >>> >>> create table X(id INTEGER primary key ON CONFLICT REPLACE); >>> create table Y(id INTEGER primary key ON CONFLICT

Re: [sqlite] System.Data.SQLite Reserved Words Bug

Thanks for fixing that so quickly. Looking forward to a new release. Patrick Earl On Sat, Jul 9, 2011 at 2:39 PM, Joe Mistachkin wrote: > > Patrick Earl wrote: >> >> System.Resources.MissingManifestResourceException was unhandled >>   Message=Could not find any

Re: [sqlite] System.Data.SQLite Reserved Words Bug

Patrick Earl wrote: > > System.Resources.MissingManifestResourceException was unhandled > Message=Could not find any resources appropriate for the specified > culture or the neutral culture. Make sure > "System.Data.SQLite.SR.resources" was correctly embedded or linked > into assembly

Re: [sqlite] Is this a BUG or am I wrong ? sub-select returns nothing when column id matches the inner query

On Tue, Jun 28, 2011 at 8:50 PM, thilo wrote: > > use SINGLE quotes, not double quotes. > bummer, Thanks a lot > i PROMISE that you won't find such an obvious bug in sqlite3 ;). sqlite uses single quotes because that's what ANSI SQL specifies. MySQL uses (or can use) double

Re: [sqlite] Is this a BUG or am I wrong ? sub-select returns nothing when column id matches the inner query

On 6/28/2011 8:45 PM, Stephan Beal wrote: > On Tue, Jun 28, 2011 at 8:42 PM, thilo wrote: > >> sqlite> select (select v from t1 where n="a") wrong,* from a1; >> > > use SINGLE quotes, not double quotes. bummer, Thanks a lot thilo -- Dipl. Ing. Thilo Jeremias Zur Rabenwiese

Re: [sqlite] Is this a BUG or am I wrong ? sub-select returns nothing when column id matches the inner query

Use single quotes instead of double sqlite> select (select v from t1 where n='a') wrong,* from a1; wrong|a|b 2000|123|456 2000|999|999 Michael D. Black Senior Scientist NG Information Systems Advanced Analytics Directorate From:

Re: [sqlite] Is this a BUG or am I wrong ? sub-select returns nothing when column id matches the inner query

string literals are enclose in single quotes not double quotes" select (select v from t1 where n='a') wrong,* from a1; On 6/28/2011 11:42 AM, thilo wrote: > select (select v from t1 where n="a") wrong,* from a1; ___ sqlite-users mailing list

Re: [sqlite] Is this a BUG or am I wrong ? sub-select returns nothing when column id matches the inner query

On Tue, Jun 28, 2011 at 8:42 PM, thilo wrote: > sqlite> select (select v from t1 where n="a") wrong,* from a1; > use SINGLE quotes, not double quotes. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ sqlite-users

Re: [sqlite] SQL-query execution bug

On Tue, Jan 18, 2011 at 12:07 PM, Vadim Smirnov wrote: > Hello! > I've found a bug in execution queries like this: > SELECT ... FROM table T JOIN table2 T2 ON T2.child=T.master > WHERE T2.attr in(SELECT value FROM table3 T3 JOIN (SELECT group, MAX(value) > FROM table4 T4

Re: [sqlite] sqlite3 ltrim behaviour bug or feature?

Hi, this is the expected behaviour. See http://www.sqlite.org/lang_corefunc.html "The ltrim(X,Y) function returns a string formed by removing any and all characters that appear in Y from the left side of X. If the Y argument is omitted, ltrim(X) removes spaces from the left side of X. " The

Re: [sqlite] 3.7.4 possible restore bug

On Wed, Jan 12, 2011 at 3:48 PM, Richard Hipp wrote: > On Wed, Jan 12, 2011 at 5:27 AM, Max Vlasov wrote: > > > On Thu, Dec 23, 2010 at 3:10 PM, Max Vlasov > wrote: > > > > > Hi, > > > I experimented with artificial power loss (using

Re: [sqlite] 3.7.4 possible restore bug

On Wed, Jan 12, 2011 at 5:27 AM, Max Vlasov wrote: > On Thu, Dec 23, 2010 at 3:10 PM, Max Vlasov wrote: > > > Hi, > > I experimented with artificial power loss (using hd box) and 3.7.4 both > > library and shell didn't restore the files to the initial

Re: [sqlite] 3.7.4 possible restore bug

Hi, 12/01/2011 12:27, Max Vlasov wrote: > On Thu, Dec 23, 2010 at 3:10 PM, Max Vlasov wrote: > >> Hi, >> I experimented with artificial power loss (using hd box) and 3.7.4 both >> library and shell didn't restore the files to the initial state. 3.6.10 >> restores

Re: [sqlite] 3.7.4 possible restore bug

On Thu, Dec 23, 2010 at 3:10 PM, Max Vlasov wrote: > Hi, > I experimented with artificial power loss (using hd box) and 3.7.4 both > library and shell didn't restore the files to the initial state. 3.6.10 > restores successfully. > This is a kind of repost, there wasn't

Re: [sqlite] 3.7.4 possible restore bug

On Thu, Dec 23, 2010 at 3:10 PM, Max Vlasov wrote: > Hi, > I experimented with artificial power loss (using hd box) and 3.7.4 both > library and shell didn't restore the files to the initial state. 3.6.10 > restores successfully. I don't know whether it's related the the

Re: [sqlite] Unicode command line bug in Windows version of sqlite3 with patch

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Christophe Deschamps wrote: > A much better solution is to use a MSYS terminal (installed by MinGW), > so you have UTF-8 command-line and data entry/display without > conversion. No need to "patch" anything. No need for msys. You can make a

Re: [sqlite] Unicode command line bug in Windows version of sqlite3 with patch

>We currently use sqlite 3.6.23. We have a big problem with characters with >accents or other special characters in path to database file, for >example in >Czech Windows XP the "Application Data" folder is translated to "Data >aplikací" so if the accented 'í' is in path the sqlite3.exe writes

Re: [sqlite] Unicode command line bug in Windows version of sqlite3 with patch

sqlite3_open[_v2] accepts all filenames in UTF-8 (although it doesn't check for valid UTF-8 string). So CP_UTF8 cannot be changed anywhere. OTOH maybe command line utility should have some logic of re-encoding of command line parameter from terminal encoding to UTF-8. But I'm not sure about that.

Re: [sqlite] is this a bug?

On Fri, Dec 18, 2009 at 07:23:24PM -0700, Valerio Aimale scratched on the wall: > Hello all, > > I've run into an interesting situation; when duplicating parenthesis > around a 'in ()' subquery, only the first row is returned. > Why only one value returned when parenthesis are duplicated?

Re: [sqlite] is this a bug?

:38 To: General Discussion of SQLite Database Subject: Re: [sqlite] is this a bug? On Fri, Dec 18, 2009 at 8:23 PM, Valerio Aimale <vale...@aimale.com> wrote: > Hello all, > > I've run into an interesting situation; when duplicating parenthesis > around a 'in ()' subquery,

Re: [sqlite] is this a bug?

On Fri, Dec 18, 2009 at 8:23 PM, Valerio Aimale wrote: > Hello all, > > I've run into an interesting situation; when duplicating parenthesis > around a 'in ()' subquery, only the first row is returned. > > This is not my real-life query, but a test that replicates the problem.

Re: [sqlite] is this a bug?

This is probably a bug in SQL parser, that doesn't reduced to one parenthesis, causing the side effect in VDBE engine, that doesn't returned all ID´s to IN evaluator in first select. This should be easily reproduced, but the fix you must wait for Richard or other that have knowledge on VDBE

Re: [sqlite] floor help (NO bug, sorry)

>I believe there is a bug here. Yes, in I my own head! We simply need to take care of integral values. The correct rounding down at 3rd decimal places using SQLite can be done so: case when cast(myValue as text) <> round(myValue) then round(myValue - 0.0005, 3) else

Re: [sqlite] floor help (plus bug found)

[ I apologize if this appears twice on the list ] Hi, At 00:11 13/12/2009, you wrote: >Sir any ida how can value rounddown floor have done > >if not possible i have make small code >i requard make function please say how can add > >i send you my rounddown funtion > >please >Cose Exmaple :

Re: [sqlite] floor help (plus bug found)

Hi, At 00:11 13/12/2009, you wrote: >Sir any ida how can value rounddown floor have done > >if not possible i have make small code >i requard make function please say how can add > >i send you my rounddown funtion > >please >Cose Exmaple : >value=10.666 >decimal=1 >Create roundd{value,decimal){

Re: [sqlite] trigger on update bug in 3.6.20?

On Wed, Nov 25, 2009 at 4:43 AM, Pavel Ivanov wrote: > Try to look at things not from the point of view of your application > but from the point of view of the SQLite itself. > > > 1. backward compatibility. It worked before upto 3.6.16. so, probably > it > > should work

Re: [sqlite] trigger on update bug in 3.6.20?

Try to look at things not from the point of view of your application but from the point of view of the SQLite itself. > 1. backward compatibility. It worked before upto 3.6.16. so, probably it > should work the same now. It was undefined behavior up to 3.6.16, it is undefined behavior now.

Re: [sqlite] trigger on update bug in 3.6.20?

On Tue, Nov 24, 2009 at 12:28 PM, Pavel Ivanov wrote: > > I am not what you mean by Oracle's Before triggers have different > concept? > > care to explain? > > Sure. When Oracle calls your before update trigger it provides you old > values of the row and storage for new

Re: [sqlite] trigger on update bug in 3.6.20?

> I am not what you mean by Oracle's Before triggers have different concept? > care to explain? Sure. When Oracle calls your before update trigger it provides you old values of the row and storage for new values of the row. You can change whatever you like in this storage and be sure that it will

Re: [sqlite] trigger on update bug in 3.6.20?

On Tue, Nov 24, 2009 at 11:25 AM, Pavel Ivanov wrote: > > yes it is risky, in general. but in this specific case, I expect no > > problems. > > just as a reference, this works just fine on mysql and oracle.. > > and used to work quite well until sqlite 3.6.16. > > I don't

Re: [sqlite] trigger on update bug in 3.6.20?

On Tue, Nov 24, 2009 at 11:49 AM, D. Richard Hipp wrote: > > On Nov 24, 2009, at 1:15 PM, Vasu Nori wrote: > > > wondering if this is a known issue in 3.6.20. > > http://www.sqlite.org/lang_createtrigger.html#undef_before > > "If a BEFORE UPDATE or BEFORE DELETE trigger modifies

Re: [sqlite] trigger on update bug in 3.6.20?

On Nov 24, 2009, at 1:15 PM, Vasu Nori wrote: > wondering if this is a known issue in 3.6.20. http://www.sqlite.org/lang_createtrigger.html#undef_before "If a BEFORE UPDATE or BEFORE DELETE trigger modifies or deletes a row that was to have been updated or deleted, then the result of the

Re: [sqlite] trigger on update bug in 3.6.20?

On Tue, Nov 24, 2009 at 10:25 AM, Pavel Ivanov wrote: > > create table t1(_id integer primary key, v integer, d integer); > > CREATE TRIGGER t1_trig BEFORE UPDATE ON t1 > > BEGIN > >update t1 SET v=OLD.v+1 WHERE NEW._id=OLD._id AND NEW.d!= OLD.d; > > END; > > I guess

Re: [sqlite] trigger on update bug in 3.6.20?

Vasu Nori wrote: > wondering if this is a known issue in 3.6.20. > > create table t1(_id integer primary key, v integer, d integer); > CREATE TRIGGER t1_trig BEFORE UPDATE ON t1 > BEGIN >update t1 SET v=OLD.v+1 WHERE NEW._id=OLD._id AND NEW.d!= OLD.d; > END; Realize that

Re: [sqlite] trigger on update bug in 3.6.20?

> create table t1(_id integer primary key, v integer, d integer); > CREATE TRIGGER t1_trig BEFORE UPDATE ON t1 > BEGIN >update t1 SET v=OLD.v+1 WHERE NEW._id=OLD._id AND NEW.d!= OLD.d; > END; I guess your trigger does something different from what you wanted to do: it changes value of v in

Re: [sqlite] Is this a bug?

-Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of J. R. Westmoreland Is there a way to get an autoincrement field without being a primary key? Yes, you can create a trigger to do this. (This also allows you great

Re: [sqlite] Is this a bug?

, 2009 1:01 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Is this a bug? J. R. Westmoreland <j...@jrw.org> wrote: > I have the following table creation statements and get an error. > > Functioning statement > > CREATE TABLE xxx (ID INTEGERPRIMARY KEY AUTOINCREMEN

Re: [sqlite] Is this a bug?

J. R. Westmoreland wrote: > I have the following table creation statements and get an error. > > Functioning statement > > CREATE TABLE xxx (ID INTEGERPRIMARY KEY AUTOINCREMENT, .) > > If I remove the PRIMARY KEY" part of the statement, according to the > docs on SQL that should be

Re: [sqlite] Is this a bug?

On Fri, Jan 23, 2009 at 12:51:07PM -0700, J. R. Westmoreland scratched on the wall: > I have the following table creation statements and get an error. > > Functioning statement > CREATE TABLE xxx (ID INTEGERPRIMARY KEY AUTOINCREMENT, .) > If I remove the PRIMARY KEY" part of the statement,

Re: [sqlite] Is this a bug?

I am not sure about the email server. You're probably correct. I spent couple of painful hours on this issue. I just moved the error printf after finalize now. Thanks Roger! -Alex On Fri, Jul 4, 2008 at 7:03 PM, Roger Binns <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash:

Re: [sqlite] Is this a bug?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex Katebi wrote: > I was able to get the attachment myself. It could be your email server. Are you sure? I was looking at the actual raw message. My mail server is postfix with messages funneled through clamassassin and spamassassin. It could be

Re: [sqlite] Is this a bug?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex Katebi wrote: > How about this one? Still no attachment. It is a mime message with two parts. The first is your message and the second is a mailing list information trailer. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6

Re: [sqlite] Is this a bug?

How about this one? On Thu, Jul 3, 2008 at 9:39 PM, Roger Binns <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Alex Katebi wrote: > > sqlite3_errmsg(db) does not provide the correct error message but > > sqlite_exec(...) does. > > The message gets cleared on

Re: [sqlite] Is this a bug?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex Katebi wrote: > sqlite3_errmsg(db) does not provide the correct error message but > sqlite_exec(...) does. The message gets cleared on various calls so you'll want to get it as early as possible after knowing there is an error. For example

Re: [sqlite] 3.5.5 Compilation failure / Bug

Ken <[EMAIL PROTECTED]> wrote: > Amalgamation fails to compile when -DSQLITE_OMIT_VIEW is defined. > Neither the nor the preprocessed sources work with -DSQLITE_OMIT macros. If you need to use -DSQLITE_OMIT, then you will need to compile on Unix using the original source code. Both the

Re: [sqlite] Is it a bug?

--- Scott Hess <[EMAIL PROTECTED]> wrote: > On 6/14/07, Joe Wilson <[EMAIL PROTECTED]> wrote: > > You can't infer a function's return type from its arguments. > > Take the hypothetical function FOO(x). If I pass it a number, it will > > return the number spelled out as TEXT, but if I pass it a

Re: [sqlite] Is it a bug?

On 6/14/07, Joe Wilson <[EMAIL PROTECTED]> wrote: You can't infer a function's return type from its arguments. Take the hypothetical function FOO(x). If I pass it a number, it will return the number spelled out as TEXT, but if I pass it a BLOB it will return its length*PI as a FLOAT. Would it

Re: [sqlite] Is it a bug?

> The code changes are not that complex. The hard part is getting > me to agree to such a change. Surely by now you have come to > better understand my views toward static typing Isn't this decision already made? Strict affinity mode is mentioned on official SQLite site suggesting that it

Re: [sqlite] Is it a bug?

--- [EMAIL PROTECTED] wrote: > Joe Wilson <[EMAIL PROTECTED]> wrote: > > > > As a possible extension one could see sqlite3_create_function taking an > > optional argument with a hint as to its return type that sqlite may use > > for sqlite3_column_decltype. But SQLite does not currently return

Re: [sqlite] Is it a bug?

Joe Wilson <[EMAIL PROTECTED]> wrote: > > As a possible extension one could see sqlite3_create_function taking an > optional argument with a hint as to its return type that sqlite may use > for sqlite3_column_decltype. But SQLite does not currently return any > column types for any ad-hoc

Re: [sqlite] Is it a bug?

--- [EMAIL PROTECTED] wrote: > Thank you Joe. At least sqlite3_column_type gives me a column type I > can use as > a hint. > > The issue is that I have a well-defined column type naming convention for my > wrapper classes to look for (INT, TEXT, FLOAT, BLOB, etc.). For binary data > fields,

Re: [sqlite] Is it a bug?

--- [EMAIL PROTECTED] wrote: > I have a user-defined function named DECRYPT, which decrypts column data > encrypted by my other UDF named ENCRYPT. > > The UDF callback function (which does the decrypting) calls > sqlite3_result_blob > after decrypting the data. Sqlite does return the data

Re: [sqlite] Failed subquery (possible bug?)

Steve Krulewitz wrote: Hey all, On sqlite 3.3.12, I see the following: create table test_in (data text, ordinal text); insert into test_in values ('foo', '0'); insert into test_in values ('bar', '1'); insert into test_in values ('baz', '2'); Running: select count(1) from test_in where

RE: [sqlite] weird (and dangerous) bug in Microsoft Compiler

ite-users@sqlite.org > Subject: Re: [sqlite] weird (and dangerous) bug in Microsoft Compiler > > did you also compile the ado .net wrapper ? > > - Original Message - > From: "Robert Simpson" <[EMAIL PROTECTED]> > To: <sqlite-users@sqlite.org> > Sent:

Re: [sqlite] weird (and dangerous) bug in Microsoft Compiler

What would you expect 9.95 to round to? Here are the simple rounding rules - Rule 1- if the remainder beyond the last digit to be reported is less than 5, drop the last digit. Rounding to one decimal place, the number 5.3467 becomes 5.3. Rule 2-if the remainder is greater than 5, increase

RE: [sqlite] weird (and dangerous) bug in Microsoft Compiler

I compiled everything from bare source myself. I maintain the ADO.NET 2.0 wrapper. > -Original Message- > From: mike cariotoglou [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 08, 2006 9:18 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] weird (and

Re: [sqlite] weird (and dangerous) bug in Microsoft Compiler

did you also compile the ado .net wrapper ? - Original Message - From: "Robert Simpson" <[EMAIL PROTECTED]> To: <sqlite-users@sqlite.org> Sent: Wednesday, November 08, 2006 4:57 PM Subject: RE: [sqlite] weird (and dangerous) bug in Microsoft Compiler I

RE: [sqlite] weird (and dangerous) bug in Microsoft Compiler

I tried that same SELECT statement in 3 builds of SQLite on VS2005. The code was called from C# using the ADO.NET 2.0 wrapper, and I got 10 all 3 times. I tried /fp:fast, /fp:strict and /fp:precise The rest of the build options were: AdditionalOptions="/GS-"

Re: [sqlite] I think lemon bug

Oh, my source is not latest one. Thanks, problem is solved. On 10/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: > > Your work-around is to say %%d instead of %d. Or (better) get the latest version of lemon where this bug is fixed. -- D. Richard Hipp <[EMAIL

Re: [sqlite] I think lemon bug

"Jong-young Park" <[EMAIL PROTECTED]> wrote: > Hi all. > > I want to use "Lemon" parser generator for my own project because of > multi-threading. > But I find the strange bug. > > I made sample calculator program for testing. > See the part of grammar file : > > expr(X) ::= expr(A) PLUS NUM(B)

Re: [sqlite] I think lemon bug

[EMAIL PROTECTED] wrote: > > Your work-around is to say %%d instead of %d. Or (better) get the latest version of lemon where this bug is fixed. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to

Re: [sqlite] Seems like a bug in the parser

On 8/23/06, Andrew McCollum <[EMAIL PROTECTED]> wrote: I find this feature useful, especially in queries which use aggregate functions, such as the following: SELECT sum(a) FROM tbl GROUP BY b The question should be what the compelling reason is to remove a useful feature. Of course it's OK

Re: [sqlite] Seems like a bug in the parser

> The question should be what the compelling reason is to remove a useful > feature. ... And *that* is exactly why Windows will always be full of security holes. I thought it was because it used the network for inter process communications (thus allowing external processes to attack it) --

Re: [sqlite] Seems like a bug in the parser

--- Kurt Welgehausen <[EMAIL PROTECTED]> wrote: > > select a from qqq group by b; > > This question was discussed on the list a year or 2 ago. > > The column a in the simple query above is meaningless; it's > an arbitrary value from each group. There are queries, > however, where a non-grouped

Re: [sqlite] Seems like a bug in the parser

On 8/23/06, Andrew McCollum <[EMAIL PROTECTED]> wrote: I find this feature useful, especially in queries which use aggregate functions, such as the following: SELECT sum(a) FROM tbl GROUP BY b The question should be what the compelling reason is to remove a useful feature. ... And *that* is

RE: [sqlite] Seems like a bug in the parser

[mailto:[EMAIL PROTECTED] Sent: Wednesday, August 23, 2006 7:02 AM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Seems like a bug in the parser > select a from qqq group by b; This question was discussed on the list a year or 2 ago. The column a in the simple query above is meaningl

Re: [sqlite] Seems like a bug in the parser

> select a from qqq group by b; This question was discussed on the list a year or 2 ago. The column a in the simple query above is meaningless; it's an arbitrary value from each group. There are queries, however, where a non-grouped column is meaningful, such as a join where the grouping column

Re: [sqlite] Seems like a bug in the parser

Joe Wilson wrote: --- [EMAIL PROTECTED] wrote: SQLite accepts the above and does the right thing with it. It is the equivalent of saying: SELECT a FROM (SELECT a,b FROM qqq GROUP BY b); Not sure what you mean by the "right thing". It's not obvious why the rows returned by this GROUP BY

<    1   2   3   >