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
ve Crozier
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Mark Stanton
Sent: 02 September 2007 21:42
To: profox@leafe.com
Subject: SQL "improvements"
I'm guessing that the new enginebehaviour whereby a group by clause
must include all the field
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
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 for querying. I can imagine th
19 matches
Mail list logo
