We have already left and gone to MSSQL.
Still keeping an eye on Firebird, but I don't have much faith.

(P.S. Hell is not that bad once it has been frozen over)

-----Original Message-----
From: csswa [mailto:csswa@...]
Sent: Wednesday, May 29, 2002 8:45 PM
To: ib-support@yahoogroups.com
Subject: [ib-support] IB dumber than a $5 calculator



I'm not fond of Interbase's casting. Right now I consider
Interbase's handling of arithmetic to be dumber than a $5
calculator. Sure, it's great for completely controlling every step
of the computational process, but is it really necessary to have to
CAST every single element of formula to ensure correct results?

There's got to be an easier way. Why not just internally cast every
computed constant/variable to the output variable type? e.g. if the
result is a double precision then internally cast all parts of the
computation to a double. If the result is a string, then type all to
string, etc.

It's enough to make me dump IB and embrace MSSQL (hell just froze
over). Or does MSSQL force you to be this finnicky when coding
stored procedures?

Gripe over. If anyone can suggest how to streamline the below
select, much appreciated.

Regards,
Andrew Ferguson
-- tag omitted due to complete lack of humour today :-)

SELECT
F_CUSTNAME AS CUSTNAME,
F_UNITNO AS UNITNO,
COUNT(F_SAMPLE_ID) AS TOTAL_SAMPLES,
MIN(F_PROCESSDATE) AS FIRST_SAMPLE,
MAX(F_PROCESSDATE) AS LATEST_SAMPLE,
MAX(F_PROCESSDATE) - MIN(F_PROCESSDATE) AS DAY_RANGE,
CAST (COUNT(F_SAMPLE_ID) AS DOUBLE PRECISION)
/
CAST((MAX(F_PROCESSDATE) - MIN(F_PROCESSDATE)) AS DOUBLE PRECISION)
AS AV_SAMP_PER_MTH
FROM T_LIMZ1_SAMPLES
GROUP BY
F_CUSTNAME,
F_UNITNO
HAVING (MAX(F_PROCESSDATE) - MIN(F_PROCESSDATE)) > 0
ORDER BY 1,3 DESC
;



To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/