us somewhat to what is commonly
allowed on such platforms. Things like Stored Procedures are unfortunately
outside our scope when it come to design considerations.
Thanks all.
On 18 October 2014 02:24, James K. Lowden jklow...@schemamania.org wrote:
On Thu, 16 Oct 2014 09:05:51 +1100
Michael
Thanks Eduardo,
a most interesting link.
On 17 October 2014 05:41, Eduardo Morras emorr...@yahoo.es wrote:
On Thu, 16 Oct 2014 09:05:51 +1100
Michael Falconer michael.j.falco...@gmail.com wrote:
Hi all,
first off I must start with an apology. I know I'm sort of doing the
wrong thing
Hi all,
first off I must start with an apology. I know I'm sort of doing the wrong
thing here as this question is NOT related to sqlite. It is a general SQL
question but I ask it here because I have great respect for the answers and
discussions I have seen on this forum over many years. I rarely
the duplicate records from
the result set? I'm assuming. I'll give that a try.
On 16 October 2014 10:05, RSmith rsm...@rsweb.co.za wrote:
On 2014/10/16 00:05, Michael Falconer wrote:
Hi all,
first off I must start with an apology. I know I'm sort of doing the
wrong//...
No need to apologise
2014 10:30, Michael Falconer michael.j.falco...@gmail.com
wrote:
Yes, I agree with the general sentiment. It is not exactly the design I
would have chosen either, but it is what exists. Design change is occurring
but for the moment we are stuck with the current schema.
If you cannot change
times, ditch the longest and shortest times, then take
the mean or average times and do the comparison that way.
On Wed, Oct 15, 2014 at 7:54 PM, Michael Falconer
michael.j.falco...@gmail.com wrote:
Igor,
Nice one. A quick test using 10 lookup trees and the same search
criteria
Hi Vance,
...yes it seems reasonable to expect the same resulting order if your
subsequent (temp creating) query is identical to that which was run
previously. However I can understand, from a theoretical and experience
point of view, why you might feel uneasy about relying on a rowid as the
Leading on from what Keith suggests above re: 'and join' can we simplify as:
Findfirst:
SELECT * FROM some_table WHERE original_expression AND new_expression LIMIT
1;
What the LIMIT 1 will return depends on what index/primary key is in
effect, sort of hoping for rowid here :-)
This appears
at 12:47 PM, Michael Falconer
michael.j.falco...@gmail.com wrote:
Leading on from what Keith suggests above re: 'and join' can we simplify
as:
Findfirst:
SELECT * FROM some_table WHERE original_expression AND new_expression
LIMIT 1;
What the LIMIT 1 will return depends on what index
