Thank you very much for your help. Richard was correct in that it was a
memory error earlier.
/Fredrik
2016-02-04 16:53 GMT+01:00 Simon Slavin :
>
> On 3 Feb 2016, at 4:21pm, Fredrik Gustafsson wrote:
>
> > 223 rc = sqlite3_exec(db, "SELECT id, date, text FROM events
> WHERE
On Thu, Feb 4, 2016 at 9:15 AM, Artur Kr?l
wrote:
> Hi,
>
> I am getting a weird behaviour when using Universal App Platform library
> v. 3.10.2.0. The problem occurs when application is build for x86 only ?
> build for arm and x64 works good.
>
> Here is the case:
> I have a wrapper from pure
>From now on I wont use "LIMIT 1" in these cases any more.
Such queries will be more readable and surely not slower.
Thank you for explanation!
Paul
5 February 2016, 14:21:35, by "Richard Hipp" :
> On 2/5/16, Paul wrote:
> >
> > Does it have any advantage or worse, a downside to have
The row still counts. Just like counting christmas presents before you open
them. The fact that someone gave you an empty wrapper only becomes apparrent
when you look inside.
-Urspr?ngliche Nachricht-
Von: sqlite-users-bounces at mailinglists.sqlite.org
[mailto:sqlite-users-bounces at
Suppose we have table:
CREATE TABLE foo(
??? id??? INTEGER PRIMARY KEY,
??? bar INTEGER
)
Does it have any advantage or worse, a downside to have "LIMIT 1" in a queries
with "... WHRE id = ?;" ?
For example:
SELECT bar FROM foo WHERE id = ? LIMIT 1;
SELECT 1 FROM foo WHERE id = ? LIMIT 1;
count(*) counts the rows of the result set selected
count(column) counts the NOT NULL values in the column of the result set
selected
count(DISTINCT column) counts the number of distinct values (excluding NULLs)
in the column of the result set selected
count(column IS NULL) is equivalent
Paul wrote:
> CREATE TABLE bar(
> id INTEGER PRIMARY KEY,
> foo TEXT UNIQUE,
> )
>
> SELECT 1 FROM bar WHERE foo = ? LIMIT 1;
>
> is statement builder is smart enough to render "LIMIT 1" suggestion useles
No, the LIMIT 1 logic is never removed.
> if we take into account the fact
All suggestions (with a bug-fix or two) gave the same results and ran in
acceptable time. Thanks to everyone for their help. I went with the
sub-SELECT solution. Not because it gave superior results but because I'm not
very familiar with sub-SELECT and it's good to have a working example in
On Fri, 5 Feb 2016 07:51:06 +
Hick Gunter wrote:
> That is because count(a) and count(*) means two different things. The first
> counts values, the second counts rows.
What if all columns of a row, are NULL?
--
Yannick Duch?ne
On Fri, Feb 5, 2016 at 11:23 AM, J Decker wrote:
> -
> var array = [1,2,,3];
> console.log( JSON.stringify( array ) );
> -
> outut : [1,2,null,3]
> ...
> So seems like having null in array for JSON is perfectly expected.
>
See also:
On 2016/02/04 3:30 PM, Keith Medcalf wrote:
> You conclusion about the Windows design goals are correct.
>
> Hardware Destroyer (power saving) was invented for the same reason (to
> maximize the rate of hardware failure through imposition of unnecessary
> thermal and mechanical stresses on all
On 2016/02/05 6:34 AM, TJ O'Donnell wrote:
> I can't argue for the correctness of including nulls in aggregate functions
> or not.
> It truly is an arbitrary decision meant for standards-makers. Yet, most
> aggregate
> function do not include nulls. Interestingly, some SQL's do include them
>
Hi Simon,
I do this type of query all the time to avoid sub queries and aggregation.
This might be what you are looking for to satisfy the elegance criteria:
SELECT r.room_id,
b.date
FROM roomr
LEFT JOIN
booking b ON r.room_id = b.room_id
LEFT JOIN
booking b2 ON
That is because count(a) and count(*) means two different things. The first
counts values, the second counts rows.
-Urspr?ngliche Nachricht-
Von: sqlite-users-bounces at mailinglists.sqlite.org
[mailto:sqlite-users-bounces at mailinglists.sqlite.org] Im Auftrag von TJ
O'Donnell
On 2/5/16, Paul wrote:
>
> Does it have any advantage or worse, a downside to have "LIMIT 1" in a
> queries with "... WHRE id = ?;" ?
> For example:
>
> SELECT bar FROM foo WHERE id = ? LIMIT 1;
> SELECT 1 FROM foo WHERE id = ? LIMIT 1;
> ... etc
>
When "id" is a UNIQUE column (or an INTEGER
I think maybe it would be more appropriate to return a blank element.
It would fill an index point, but be skipped and unused in cases of
iterating the loop...
http://www.2ality.com/2013/07/array-iteration-holes.html
Was thinking that javascript forEach et al. methods skipped null (or
undefined
16 matches
Mail list logo
