Ed Leafe wrote:
> On Sep 3, 2007, at 6:44 AM, Mark Stanton wrote:
>
>
>> However the crux of the matter is the same in both, without this new
>> requirement I can include fields I know to be non-variant
>>
>
> You may know this, but there is nothing in either SQL or the
> database t
Set EngineBevavior 80 is a default :(
-Original Message-
From: Mark Stanton [mailto:[EMAIL PROTECTED]
Sent: Monday, September 03, 2007 6:45 PM
To: profox@leafe.com
Subject: Re: SQL "improvements"
> And why is is that any simpler (or better, or cleaner, or...)
> t
On 9/3/07, Ed Leafe <[EMAIL PROTECTED]> wrote:
>
> Of course! Clarity and precision have no place in database code! As
> long as it's brief, it's good!
>
Now, you're talking
A+
jml
___
Post Messages to: ProFox@leafe.com
Subscription Mainten
On Sep 3, 2007, at 6:44 AM, Mark Stanton wrote:
> Iggzackerley! And the extra code I now need to write & the database
> needs to perform seems to me a step backwards rather than forwards.
> Thank God (Calvin?) for "SET ENGINEBEHAVIOR (sic)"
Of course! Clarity and precision have no place
On Sep 3, 2007, at 6:44 AM, Mark Stanton wrote:
> However the crux of the matter is the same in both, without this new
> requirement I can include fields I know to be non-variant
You may know this, but there is nothing in either SQL or the
database that requires/enforces this. And there
Mark Stanton wrote:
>> Out of memory I could say that when you have 10 or 20 fields in
>> your output but the group by is by 4 or 5 of them, then using max()
>> will give you more readable code
>
> Hmmm, I have to say I'm with Ed on this, "max" of something non-
> numeric looks odd to my eyes.
Ha
> And why is is that any simpler (or better, or cleaner, or...)
> than:
>
> select EmployeeId, EmpName, sum(salary) ;
> from Employee ;
> group by EmployeeId, EmpName
Iggzackerley! And the extra code I now need to write & the database
needs to perform seems to me a step backwards rather than fo
In article <[EMAIL PROTECTED]>, Dave Crozier wrote:
> The "new" behaviour only brings VFP into line with standard ANSI standards.
As I said, that's what I suspected
> It is VFP that previously had its own standard(s). However the standard
> behaviour can simply be made equivalent to the old meth
> Out of memory I could say that when you have 10 or 20 fields in
> your output but the group by is by 4 or 5 of them, then using max()
> will give you more readable code
Hmmm, I have to say I'm with Ed on this, "max" of something non-
numeric looks odd to my eyes.
Mark
__
Hi Stephen,
> why are you using the group by? Is it the sum of a column or
> another aggregate?
Two situations, only the first is an aggregation.
However the crux of the matter is the same in both, without this new
requirement I can include fields I know to be non-variant across my group in
t
Mark,
The "new" behaviour only brings VFP into line with standard ANSI standards.
It is VFP that previously had its own standard(s). However the standard
behaviour can simply be made equivalent to the old method and when you look
at it closely the standard is more logical.
Dave Crozier
-Ori
Life-Cycle Approaches"
- Original Message -
From: "Ed Leafe" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 03, 2007 7:24 AM
Subject: Re: SQL "improvements"
On Sep 2, 2007, at 7:58 PM, Ricardo Aráoz wrote:
> select EmployeeI
Ed Leafe wrote:
> On Sep 2, 2007, at 7:58 PM, Ricardo Aráoz wrote:
>
>> select EmployeeId, EmpName, sum(salary) ;
>> from Employee ;
>> group by EmployeeId
>>
>> This would have sense but it is easily done with :
>
> To a human, perhaps, but to a database engine, there is no
> constraint
On Sep 2, 2007, at 7:58 PM, Ricardo Aráoz wrote:
> select EmployeeId, EmpName, sum(salary) ;
> from Employee ;
> group by EmployeeId
>
> This would have sense but it is easily done with :
To a human, perhaps, but to a database engine, there is no
constraint that the ID and name be a 1:1
Stephen the Cook wrote:
> Mark Stanton <> wrote:
>> I'm guessing that the new enginebehaviour whereby a group by clause
>> must include all the fields that are selected is to follow a new SQL
>> standard, is that right?
>>
>> Regardless of the source, why is this considered an improvement? It
>>
Mark Stanton <> wrote:
> I'm guessing that the new enginebehaviour whereby a group by clause
> must include all the fields that are selected is to follow a new SQL
> standard, is that right?
>
> Regardless of the source, why is this considered an improvement? It
> seems to me to reduce my optio
On Sep 2, 2007, at 4:42 PM, Mark Stanton wrote:
> I'm guessing that the new enginebehaviour whereby a group by clause
> must include all the fields that are selected is to follow a new SQL
> standard, is that right?
>
> Regardless of the source, why is this considered an improvement? It
> seems t
Mark Stanton wrote:
> I'm guessing that the new enginebehaviour whereby a group by clause
> must include all the fields that are selected is to follow a new SQL
> standard, is that right?
>
> Regardless of the source, why is this considered an improvement? It
> seems to me to reduce my options
18 matches
Mail list logo
