thought I had already done), I got the same result as you.
> > No problem with the "bit quick", I am always clear and my English is
maybe
> > approximative.
> > I have retried your statements on my PC and one of my collegues, and it
> > failed in both cases.
> > The tested versions of SQL are
> > Microsoft SQL Server 7.00 - 7.00.699 (Intel X86)
> > May 21 1999 14:08:18
> > Copyright (c) 1988-1998 Microsoft Corporation
> > MSDE on Windows NT 5.0 (Build 2195: )
> > and
> > Microsoft SQL Server 7.00 - 7.00.699 (Intel X86)
> > May 21 1999 14:08:18
> > Copyright (c) 1988-1998 Microsoft Corporation
> > MSDE on Windows NT 4.0 (Build 1381: Service Pack 5)
> > I have no other version of MS SQL where to test it further for the
moment.
> > As the PC of my collegue runs the same OS as yours, should we conclude
that
> > wer are we in front of a bug specific to MSDE?
> > > I'm sorry, I was a bit quick. I understand (now) what you are saying.
> > > I don't get the same result as you:
> > > I execute below from QA:
> > > SET NOCOUNT ON
> > > CREATE TABLE TEST(FLT FLOAT)
> > > GO
> > > INSERT INTO TEST (FLT) VALUES (0.300000011920929)
> > > SELECT * FROM TEST WHERE FLT = 0.300000011920929
> > > SELECT COUNT(*) FROM TEST WHERE FLT = 0.300000011920929
> > > DROP TABLE TEST
> > > And get below result:
> > > FLT
> > > ---------------------------
> > > 0.30000001192092901
> > > -----------
> > > 1
> > > Microsoft SQL Server 7.00 - 7.00.842 (Intel X86)
> > > Mar 2 2000 06:49:37
> > > Copyright (c) 1988-1998 Microsoft Corporation
> > > Desktop Edition on Windows NT 5.0 (Build 2195: )
> > > --
> > > Tibor Karaszi, SQL Server MVP
> > > Please reply to the newsgroup only, not by email.
> > > > The discretization is not really a problem for me but well the
> > inconsistancy
> > > > between the result of the 2 selects.
> > > > Why in one case the select the discretization seems to be redone (OK
for
> > me)
> > > > and not in the other case?
> > > > The data I have to store is a C "double" which matches the range of
a
> > SQL
> > > > "float" (ranging from - 1.79E + 308 through 1.79E + 308) while
"decimal"
> > and
> > > > "numeric" types range from - 10^38 -1 through 10^38 - 1.
> > > > > Eric,
> > > > > The float (and real) datatypes are, per definition not precise
> > datatypes.
> > > > This means
> > > > > that they span a wide range , but SQL Server can not represent all
> > values
> > > > within that
> > > > > range. You can easily see from the SELECT * that the values stored
is
> > > > _not_ the same
> > > > > as you entered.
> > > > > Use some other datatype (DECIMAL, for instance) if you need exact
> > numeric
> > > > > representation.
> > > > > --
> > > > > Tibor Karaszi, SQL Server MVP
> > > > > Please reply to the newsgroup only, not by email.
> > > > > > My problem can be reproduced by the following SQL statements:
> > > > > > CREATE TABLE TEST
> > > > > > FLT FLOAT
> > > > > > )
> > > > > > INSERT INTO TEST (FLT) VALUES (0.300000011920929)
> > > > > > SELECT * FROM TEST WHERE FLT = 0.300000011920929
> > > > > > SELECT COUNT(*) FROM TEST WHERE FLT = 0.300000011920929
> > > > > > DROP TABLE TEST
> > > > > > which returns:
> > > > > > (1 row(s) affected)
> > > > > > FLT
> > > > > > -----------------------------------------------------
> > > > > > 0.30000001192092896
> > > > > > (1 row(s) affected)
> > > > > > -----------
> > > > > > 0
> > > > > > (1 row(s) affected)
> > > > > > The select * returns a row but the select count(*) returns 0
instead
> > of
> > > > 1?!
> > > > > > Can somebody tell me if this is really a bug and if there is a
> > > > workaround to it
> > > > > (besides reducing the number of digits to avoid discretization
> > problem) ?
> > > > > > Thanks,
> > > > > > PS: I have made this test on MSDE 1.0 with service pack 2.
by