As we've seen earlier, many floats are not correctly synchronized by SQL Data Compare.
Previously, it was suggested that appending e0 onto the end of a float would make SQL process it as a float instead of as a decimal. Here is a case where that does not work, and it may be an error in how Red Gate generates the decimal value for a float.
- Code: Select all
create table dbo.FloatTest (PK INT PRIMARY key, Fraction FLOAT)
insert into dbo.FloatTest (PK, Fraction) Values (1, 0.07689223240363979e0)
DECLARE @F1 FLOAT
SELECT @F1 = Fraction FROM dbo.FloatTest
--prints 0.07689223240363979 -- looks good, right?
Also create this table on another database - but without the INSERT.
Now use SQL Data Compare and see what value is generated:
INSERT INTO [dbo].[FloatTest] ([PK], [Fraction]) VALUES (1, 0.0768922324036398)
--This rounds to 16 places, it seems, or 15 significant figures.
As in the original report, this is the incorrect binary value for the float. Here's the new part: adding on e0 is ALSO INCORRECT:
INSERT INTO [dbo].[FloatTest] ([PK], [Fraction]) VALUES (1, 0.0768922324036398e0)
So, would it be possible to get Red Gate Data Compare's Synchronize to synchronize floats correctly? We have been manually appending e0 onto floats for some months now when synchronizing. Now we see this is not enough.