Thanks again Helen and Alan!

> Be certain that the issue is actually fixed. I hope you have
> a testbed on which you can verify that you are getting all
> and only the results you want.

Well one of my beta testers actually pointed out a way to check that it is
correct (a bookkeeper who pointed out that there was a problem with my
"accounts receivable" report in the first place) based on a formula
comparing a couple of months reports to another report of mine. Since it's
only off by about the 60-70 cents (again, presumably because floating point
issues) from totalling nearly 1000 rows and nearly $100,000 in values, I
feel fairly certain it's right.

> That apart, it's rarely (if ever ???) appropriate to use
> DISTINCT for output that you're going to apply GROUP BY to.
> I leave you to figure out why. :-) I'm sure it's not what
> you wanted there.
>
> It's not what you want here, either (assuming BillingItemID
> is the PK). However, the engine will do it anyway, and it's
> a very costly piece of non-necessity.

Yes, BILLINGITEMID is the PK...I understand, DESTINCT is gone. Thanks. :)

> If you are stuck with these (highly inadvisable) floats then

I'm not, I can change them...I just want to know the best way to do so with
my existing tables and data.

> >What is the best way to safely convert my tables and data?
>
> There's a loaded question! But it's highly desirable to
> understand the issues with floating point types. Rule Number
> One would
> be: don't trust Paradox's Numeric type...

Well Paradox is long gone at this point, I actually meant, what is the best
way to safely convert my Firebird tables and data from my FLOAT to NUMERIC
or DECIMAL?

BTW, I'm using Firebird 1.5.

> Hang in there for Set to come online. He loves SQL puzzles
> like yours.

I look forward to any insights!

-Anthony