Hello,
thank you for your reply, that works for me. To give a context and a
background; my comment was implying a change of design by adding an
abstraction layer between the data and the representation, a change of
raw-data storage with the support of a middle-man-linker e.g async data
events, but
On Monday, 24 February, 2014 21:53, mm.w <0xcafef...@gmail.com> said:
>I don't want to be annoying but why nowadays people are
>sub-abusing-sub-selecting instead of using JOINs? moreover, that is in
>most cases faster (a lot) and certainly more Human Readable.
Neither JOIN nor LEFT JOIN will wor
On 25 Feb 2014, at 4:31am, Keith Medcalf wrote:
> does generate a plan with only one execution of each correlated subquery, but
> does not give me access to the intermediate results
You might experiment with creating a view for the subquery instead of for the
query as a whole:
CREATE VIEW ra
Hello,
I don't want to be annoying but why nowadays people are
sub-abusing-sub-selecting instead of using JOINs? moreover, that is in most
cases faster (a lot) and certainly more Human Readable.
Best Regards
On Mon, Feb 24, 2014 at 8:34 PM, Keith Medcalf wrote:
>
> Previous send munged. If i
Previous send munged. If it managed to make it properly, my apologies for
posting the same message twice.
Using the following schema:
CREATE TABLE TKRawData
(
EmpNo text collate nocase not null,
CustNo integer not null,
JobNo integer not null,
RawYear integer not null,
RawMonth integer no
Using the following schema:
CREATE TABLE TKRawData
(
EmpNo text collate nocase not null,
CustNo integer not null,
JobNo integer not null,
RawYear integer not null,
RawMonth integer not null,
RawDays real not null,
primary key (EmpNo, JobNo, CustNo, RawYear, RawMonth)
);
CREATE TABLE TKCla
6 matches
Mail list logo
