Re: [sqlite] sqlite3_open() takes 1.5 seconds

**I REREAD Keiths reply, then Alex's second question I goofed thinking that Keith was saying the attributes were what was causing the slow downs, but I missed the point of Alex's question. I had written the following, re-read the posts above, went OH CRAP, and decided to post anyways with the

Re: [sqlite] SQLite strong-typing [WAS: inner vs. outer join inconsistency]

The problem only arises if you do not properly type your application.  Why not just "pretend" it is strongly typed, use the correct types, and you will achieve your onjective. Or is the complaint really just that  SQLite does not barf when you screw up? --- Sent from Samsung Mobile 

Re: [sqlite] SQLite strong-typing [WAS: inner vs. outer join inconsistency]

On Fri, Mar 8, 2013 at 1:26 PM, James K. Lowden wrote: > On Thu, 7 Mar 2013 19:20:44 +0100 > Petite Abeille wrote: >> Yeah? 'cool' is not necessarily how I would describe it? having a >> check constraint 'magically' coerce - change! - the inserted data >> type is? well? not cool. I would call it

Re: [sqlite] SQLite strong-typing [WAS: inner vs. outer join inconsistency]

If I have any doubt, I add .5 (or .05, .005, whatever) before the operation. I know that breaks algebraic rounding, but that's one I live with. -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of James K. Lowden Sent: Friday, Ma

Re: [sqlite] SQLite strong-typing [WAS: inner vs. outer join inconsistency]

On Thu, 7 Mar 2013 18:45:23 + Simon Slavin wrote: > what do you think the desired behaviour would be for > > CAST('0.9' AS INTEGER) > > I know what I want. Perhaps this can be fixed in SQLite4. Sorry, but CAST is not a math function. There's probably a language somewhere out th

Re: [sqlite] Bug on real operations

Thank you guys, and sort for my bad explanation about what I want. I understand that double problems very well, I will continue working with round. Regards, Israel Lins Em 08/03/2013, às 16:14, "Marc L. Allen" escreveu: > Yes.. for what it's worth, I've had this very same problem on MS SQL 20

Re: [sqlite] SQLite strong-typing [WAS: inner vs. outer join inconsistency]

On Thu, 7 Mar 2013 07:36:25 -0600 "Michael Black" wrote: > Personally I think this behavior is horrid. ... > Why is this behavior allowed now? As Zero Mostel sang: "Tradition!" See your handy atoi() man page. :-) I don't know if that's really why, but it's not as if there's no prior art.

Re: [sqlite] SQLite strong-typing [WAS: inner vs. outer join inconsistency]

On Thu, 7 Mar 2013 19:20:44 +0100 Petite Abeille wrote: > > In conclusion, if you want to allow affine type conversions on > > INSERT, but not disallow values that cannot be so converted, then > > CHECK(my_column = CAST(my_column AS )) works. And if you want > > to disallow values of incorrect t

Re: [sqlite] Bug on real operations

Yes.. for what it's worth, I've had this very same problem on MS SQL 2008. Comparing floating point values in their raw form is always dangerous. It just works so much more often than not that it's easy to forget until you get that one number that doesn't work. The solution for MS SQL was con

Re: [sqlite] How can I improve this query?

On Wed, 6 Mar 2013 07:20:51 -0800 (PST) Yuzem wrote: > Given the same schema, I can list all genres with one movie by genre: > SELECT genres, movies FROM genres GROUP BY genres; HAVING count(movie) = 1 The HAVING clause does for aggregates what WHERE does for data. --jkl

Re: [sqlite] Bug on real operations

On 8 Mar 2013, at 6:24pm, Israel Lins Albuquerque wrote: > I don't know how postgres handle this, may be I can check Postgres has special datatypes used especially to handle problems like this. It has both artbitrary precision and monetary datatypes. If you present your problem to postgres

Re: [sqlite] Bug on real operations

I know that very well. I don't know how postgresql handle this, may be I can check, I just charring by problem to brainstorm if sqlite may do or not what postgresql do. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-b

Re: [sqlite] Bug on real operations

On 7 Mar 2013, at 6:03pm, Israel Lins Albuquerque wrote: > But in sqlite for some reason they are: > 3.5527136788005e-15, 0, -3.5527136788005e-15 > > I thing this can be a bug on calculation of doubles. Please read these:

Re: [sqlite] Bug on real operations

I know that. I don't know how postgresql handle this, may be I can check, I just charring by problem to brainstorm if sqlite may do or not what postgresql do. Em 08/03/2013, às 15:06, Israel Lins Albuquerque escreveu: > But I see this as a workaround, and not a solution. > Is that the way I

Re: [sqlite] Bug on real operations

I don't see your "problem". 22.35 cannot be accurately represented in floating point. It's just some display systems will hide it from you. What exactly is it that you can't do or that is coming out wrong? Stop trying to make sense out of comparing floats -- it's a bad idea. main() { floa

Re: [sqlite] Bug on real operations

On Fri, Mar 8, 2013 at 1:06 PM, Israel Lins Albuquerque < israelin...@yahoo.com.br> wrote: > The problem is not comparisons the problem is when I do something like > this: > CREATE TABLE tb (a REAL); > INSERT INTO tb (a) VALUES(0); > UPDATE tb SET a = a + 5.45; > UPDATE tb SET a = a + 16.9; > The

Re: [sqlite] Bug on real operations

And didn't we go through this a while ago... Sqlite3's precision is 14...sometimes 15 sqlite> select round(22.35-(5.45+16.9),15); 4.0e-15 sqlite> select round(22.35-(5.45+16.9),14); 0.0 So this also works: sqlite> select round(22.35 - (5.45 + 16.9),14), 22.35 = round((5.45 + 16.9),14), round(

Re: [sqlite] Bug on real operations

The problem is not comparisons the problem is when I do something like this: CREATE TABLE tb (a REAL); INSERT INTO tb (a) VALUES(0); UPDATE tb SET a = a + 5.45; UPDATE tb SET a = a + 16.9; SELECT a FROM tb; Gives visually right answer: 22.35 But putting on a double variable gives me 22.349994859

Re: [sqlite] Bug on real operations

But I see this as a workaround, and not a solution. Is that the way I'm using to 'solve' this. Em 08/03/2013, às 14:11, Michael Black escreveu: > Nobody should expect float comparisons like that to work. > If they do they're asking for trouble. > All you're seeing is what the database is letting

Re: [sqlite] Bug on real operations

And...the right way to do this which should work on all databases...rounding any answers to the max precision you asked for. sqlite> SELECT round(22.35 - (5.45 + 16.9),2), 22.35 = round((5.45 + 16.9),2), round((5.45 + 16.9) - 22.35,2); 0.0|1|0.0 -Original Message- From: sqlite-users-boun

Re: [sqlite] Report Bugs Against SQLite

https://groups.google.com/forum/?fromgroups#!topic/csharp-sqlite/HQO0OwDm0kk http://code.google.com/p/csharp-sqlite/issues/detail?id=151 -- -- -- --Ô¿Ô-- K e V i N On Thu, Mar 7, 2013 at 9:32 AM, 源子陌 wrote: > Hello! I'm Chinese,please forgive my poor English.Now I'm

Re: [sqlite] Bug on real operations

Nobody should expect float comparisons like that to work. If they do they're asking for trouble. All you're seeing is what the database is letting you see. Their "0" is not really "0". Try this in your friendly C compiler main() { double d = 22.35-(5.45+16.9); printf("%f\n",d);

[sqlite] Bug on real operations

An example speaks more than words: Execute this: SELECT 22.35 - (5.45 + 16.9), 22.35 = (5.45 + 16.9), (5.45 + 16.9) - 22.35; The expected result on almost databases is: 0.0, true or 1, 0.0 But in sqlite for some reason they are: 3.5527136788005e-15, 0, -3.5527136788005e-15 I thing this can be a

[sqlite] Report Bugs Against SQLite

Hello! I'm Chinese,please forgive my poor English.Now I'm using SQLite for Windows Phone(Community.CsharpSqlite.WP.dll),but it doesn't work if selection condiction contains Chinese.For example,if the selecting sentence is like this: select * from nearplace where city1="西安“ it will show this pict

Re: [sqlite] Don't passes next tests on FreeBSD: atof1-*

And if set tcl_precision ... #!/usr/local/bin/tclsh8.6 # do_test atof1-1.$i.1 package require platform puts "\nplatform: [platform::generic]" set tcl_precision 15 puts "sqlite version: [package require sqlite3]" sqlite db :m

Re: [sqlite] SQLite - disk I/O error only on virtual machine

Problem solved. It was shared folder issue ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Don't passes next tests on FreeBSD: atof1-*

Excuse me, the test (test/atof1.test) of sqlite3 distribution, of course. It is guilty? Or tcl real to text conversation? Why only on the platform x32. Thanks. On Fri, Mar 8, 2013 at 3:10 PM, Richard Hipp wrote: > On Fri, Mar 8, 2013 at 6:00 AM, Pavel Volkov wrote: > >> And more tests. Perhaps o

Re: [sqlite] Don't passes next tests on FreeBSD: atof1-*

Hello again. This problem was initially detected in the test "test/atof1.test", only on x32 platform. On x64 it work correct. On Fri, Mar 8, 2013 at 2:54 PM, Richard Hipp wrote: > On Fri, Mar 8, 2013 at 5:34 AM, Pavel Volkov wrote: > >> Hello. This is new test that illustrates the problem: >> >

Re: [sqlite] Don't passes next tests on FreeBSD: atof1-*

On Fri, Mar 8, 2013 at 6:00 AM, Pavel Volkov wrote: > And more tests. Perhaps one of the problems in converting real -> text? > Binary to decimal conversion is *the* problem. TCL uses an infinite precision integer math library to do exact binary to decimal conversion. SQLite does not have acces

Re: [sqlite] Don't passes next tests on FreeBSD: atof1-*

And more tests. Perhaps one of the problems in converting real -> text? #!/usr/local/bin/tclsh8.6 # do_test atof1-1.$i.1 package require platform puts "\nplatform: [platform::generic]" puts "sqlite version: [package require sq

Re: [sqlite] Don't passes next tests on FreeBSD: atof1-*

On Fri, Mar 8, 2013 at 5:34 AM, Pavel Volkov wrote: > Hello. This is new test that illustrates the problem: > SQLite only claims to convert floating binary to decimal and back again with an accuracy of 14 significant digits. Going much beyond that requires the use of infinite precision integer

Re: [sqlite] Don't passes next tests on FreeBSD: atof1-*

Hello. This is new test that illustrates the problem: #!/usr/local/bin/tclsh8.5 package require platform puts "\nplatform: [platform::generic]" puts "sqlite version: [package require sqlite3]" sqlite db test.db set xf [format