Re: [sqlite] Return Value from sqlite3_exec()

Which is where you put into the decision 'black box' of your program a check to see how many rows were modified. If something was supposed to be changed, but zero rows were updated, throw an alert. If one or a reasonable amount were changed, don't inform the user. If more than a reasonable

Re: [sqlite] Question about aggregate returning empty row

That's SQL standard -- query with aggregate functions always return at least one row. Pavel On Fri, Feb 22, 2013 at 12:06 PM, Pierre Chatelier wrote: > Hello, > > [tested under 3.6.12 and 3.7.15.2] > > I have a question regarding the use of aggregate functions. > > Let's

Re: [sqlite] Ongoing SELECT sees INSERTed rows.

On Thu, 21 Feb 2013 10:32:51 -0800 (PST) Peter Aronson wrote: > an outer select loop was reading records, and an inner select loop > was inserting records based on the records found into the same > table.  For every row, this design requires 2 trips to the database. Besides

Re: [sqlite] column totals

Paul Sanderson wrote: > SELECT cat, COUNT(*) AS occ, COUNT(DISTINCT tes) AS uni, COUNT(tag) AS > tagged FROM rtable WHERE qu > 0 AND qu < 4 GROUP BY qu > > The table would look something like > > 1 54 3 > 2 26 4 > 3 56 8 > > I want to modify the above sql query to sum the

[sqlite] column totals

I have the following query that produces a summary table SELECT cat, COUNT(*) AS occ, COUNT(DISTINCT tes) AS uni, COUNT(tag) AS tagged FROM rtable WHERE qu > 0 AND qu < 4 GROUP BY qu The table would look something like 1 54 3 2 26 4 3 56 8 I want to modify the above sql

Re: [sqlite] Return Value from sqlite3_exec()

Thanks for your replies. What you have all said makes sense (and, in my defense, I did suggest that a nonsense - but properly formed - SQL statement could still be processed "OK"). :-) I first noticed this situation when studying the sample code for the "SmartDB" C++ wrapper for SQLite. The

Re: [sqlite] Return Value from sqlite3_exec()

On 22 Feb 2013, at 10:23pm, Simon Slavin wrote: > DELETE FROM customers WHERE name = "John Johnson" That should of course have been DELETE FROM customers WHERE name = 'John Johnson' I'm terribly sorry to have shamed the SQLite community this way. Simon.

Re: [sqlite] Return Value from sqlite3_exec()

In your example, the only way SQLite can do what you expect is to notice that your UPDATE didn't modify any rows. But you don't want an UPDATE statement throwing errors simply because it didn't modify any rows. There are many situations where that happens and is considered normal behavior.

Re: [sqlite] Return Value from sqlite3_exec()

On Fri, Feb 22, 2013 at 05:15:15PM -0500, Frederick Wasti scratched on the wall: > So, my question is: Is it correct for sqlite3_exec() to return SQLITE_OK if > the SQL query is doomed to failure (but is otherwise properly formed)? The SQL query did not fail. It did exactly what you asked:

Re: [sqlite] Return Value from sqlite3_exec()

On 22 Feb 2013, at 10:15pm, Frederick Wasti wrote: > From the documentation on sqlite3_exec(), it seems as if it should return > SQLITE_OK (=0) upon processing a successful SQL query. However, I was a > bit surprised to see that an SQL statement such as "UPDATE table1 SET >

Re: [sqlite] SQLite on a Mac: PHP doesn't know about :-(

On 22 Feb 2013, at 9:35pm, Didier Morandi wrote: > As far as I understood, SQLite 3 only understands PDO (as I'm > implementing a program in PHP.) This is why I talked about OOP. I > thought everyone knew that OOP means Object Oriented Programming and > PDO is the OOP

[sqlite] Return Value from sqlite3_exec()

[A "newbie to SQLite" here...] >From the documentation on sqlite3_exec(), it seems as if it should return SQLITE_OK (=0) upon processing a successful SQL query. However, I was a bit surprised to see that an SQL statement such as "UPDATE table1 SET site='Site1' WHERE site='garbage' (where garbage

Re: [sqlite] SQLite on a Mac: PHP doesn't know about :-(

On Fri, Feb 22, 2013 at 4:47 PM, Gregory Moore wrote: > It was my understanding that any version of SQLite is written using the C > programming language which happens to be a procedural language (as in not > OOP) so I'm not sure why OOP is even part of the discussion. >

Re: [sqlite] SQLite on a Mac: PHP doesn't know about :-(

It was my understanding that any version of SQLite is written using the C programming language which happens to be a procedural language (as in not OOP) so I'm not sure why OOP is even part of the discussion. Or maybe I just need to be educated further. :-) Greg Moore thewatchful...@gmail.com

Re: [sqlite] SQLite on a Mac: PHP doesn't know about :-(

Ladies and Gentlemen, As far as I understood, SQLite 3 only understands PDO (as I'm implementing a program in PHP.) This is why I talked about OOP. I thought everyone knew that OOP means Object Oriented Programming and PDO is the OOP way of programming with PHP. Anyway, I do not wish to spam this

Re: [sqlite] SQLite on a Mac: PHP doesn't know about :-(

On 22 Feb 2013 at 20:51, Didier Morandi wrote: > very reason why noone (but Geeks) will ever move from VBScript to > PowerShell. Richard, I will not start learning OOP at 62 to be able to > use SQLite. Sorry for that. I'll stick to MySQL and good old > procedural PHP.

Re: [sqlite] SQLite on a Mac: PHP doesn't know about :-(

On Feb 22, 2013, at 9:51 PM, Didier Morandi wrote: > . You seem to be missing the point entirely. No one mentioned anything about OOP at all, whatever that is. Merely that you may be better off using a more contemporary version of SQLite. That's all.

Re: [sqlite] SQLite on a Mac: PHP doesn't know about :-(

did not know that. Thanks. 2013/2/22 Simon Slavin : > > On 22 Feb 2013, at 7:41pm, Didier Morandi wrote: > >> I then installed MAMP on my Mac > > Why ? OS X includes Apache which includes PHP which includes the sqlite3 > library.

Re: [sqlite] SQLite on a Mac: PHP doesn't know about :-(

Richard, I understand your position, the new version is aged 6 years already, there is obiously no reason to support the previous one. But everyone should understand that OOP is not a necessity in IT life. I know *a lot* of people who hate OOP just because it is not the way a computer works. A

Re: [sqlite] SQLite on a Mac: PHP doesn't know about :-(

On 22 Feb 2013, at 7:41pm, Didier Morandi wrote: > I then installed MAMP on my Mac, but the PHP 5.4.10 distributed with > MAMP doesn't have the SQLite params required in its php.ini Why ? OS X includes Apache which includes PHP which includes the sqlite3 library.

Re: [sqlite] Question about aggregate returning empty row

I would think so. You're asking for the minimum value of what is encountered. Follows along the line of count as well. The minimum return is going to be zero or null (I've not checked), but, you're asking for an absolute answer that will return some sort of value. On Fri, Feb 22, 2013 at 3:06

Re: [sqlite] SQLite on a Mac: PHP doesn't know about :-(

SQLite 2.x shouldn't be used. Its old, and I'm not even sure its in 'maintenance mode' anymore. The PHP version you've installed via WAMP includes the libraries for SQLite 2.x but PROBABLY not for SQLite 3.x by default. You'll need to install the packages.

Re: [sqlite] SQLite on a Mac: PHP doesn't know about :-(

On Fri, Feb 22, 2013 at 2:41 PM, Didier Morandi wrote: > Hello Friends, > > A new SQLite Chap in the Team, here. > I successfully installed on my PC/Windoz WAMP and SQLite 2.8.x (I do > not know anything about PDO...) and built my first appli. Works fine, > thanks. > I

[sqlite] SQLite on a Mac: PHP doesn't know about :-(

Hello Friends, A new SQLite Chap in the Team, here. I successfully installed on my PC/Windoz WAMP and SQLite 2.8.x (I do not know anything about PDO...) and built my first appli. Works fine, thanks. I then installed MAMP on my Mac, but the PHP 5.4.10 distributed with MAMP doesn't have the SQLite

Re: [sqlite] :memory: performance in sqlite 3.6

On 22 Feb 2013, at 8:31, Eduardo Morras wrote: The only thing i can think that explain it is compilation options, specifically SQLITE_TEMP_STORE=0. If you do pragma temp_store=2, does it work better? Nope. I did check all this stuff out, got ideas from people in the #sqlite IRC channel,

Re: [sqlite] :memory: performance in sqlite 3.6

On 22 Feb 2013, at 8:07, Stephen Chrzanowski wrote: I think I missed something; For clarification, you mention that you're running the tests and are monitoring memory use but (And here's what I'm missing) you don't see a memory load against the application? I do see a memory load against

Re: [sqlite] Faster query result

On Fri, Feb 22, 2013 at 9:56 AM, jose isaias cabrera wrote: > > Greetings. > > which one is faster... > > #1. > > SELECT id FROM LSOpenJobs WHERE bdate BETWEEN '2012-01-01' AND '2012-12-31'; > > or this one... > > #2 > > SELECT id FROM LSOpenJobs WHERE bdate IN

Re: [sqlite] Faster query result

Hello José, #1: no hash/bsearch required. Regards, Etienne - Original message - From: jose isaias cabrera To: General Discussion of SQLite Database Subject: [sqlite] Faster query result Date: Fri, 22 Feb 2013 10:56:08 -0500

Re: [sqlite] Faster query result

On 2/22/2013 10:56 AM, jose isaias cabrera wrote: which one is faster... #1. SELECT id FROM LSOpenJobs WHERE bdate BETWEEN '2012-01-01' AND '2012-12-31'; or this one... #2 SELECT id FROM LSOpenJobs WHERE bdate IN ('2012-01-01', ..., '2012-12-31)'; where , ..., would have all the rest of

[sqlite] Faster query result

Greetings. which one is faster... #1. SELECT id FROM LSOpenJobs WHERE bdate BETWEEN '2012-01-01' AND '2012-12-31'; or this one... #2 SELECT id FROM LSOpenJobs WHERE bdate IN ('2012-01-01', ..., '2012-12-31)'; where , ..., would have all the rest of the dates. Thanks. josé

[sqlite] FTS3 prefix wildcard

Hi All, A user wants to be able to query my FTS3 database using a preceeding wildcard. From reading back through the mailing list it looks like SQLite may not support this (for very understandable reasons) but I cannot find any mention of this in the docs. Is this limitation? To get round this I

Re: [sqlite] :memory: performance in sqlite 3.6

On Wed, 20 Feb 2013 12:06:17 -0600 Seebs wrote: > On 20 Feb 2013, at 11:47, Simon Slavin wrote: > > > On 20 Feb 2013, at 5:32pm, Seebs wrote: > > > >> First: The SQL is completely trivial. > >> Second: I am not having performance problems with sqlite, I am

Re: [sqlite] :memory: performance in sqlite 3.6

I think I missed something; For clarification, you mention that you're running the tests and are monitoring memory use but (And here's what I'm missing) you don't see a memory load against the application? If you're using the :MEMORY: database, throwing anything at it should bump up the count