© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Hi Damon,
There are two different issues at play here. Both are related to floating point.
First issue:
To detect differences in floating point columns, the tool converts first to string, but due to rounding errors and internal representation of data , it might still detect differences (even when not apparent with a simple manual select).
This can be alleviated using the --float-precision option:
http://
Second issue:
The tool prefers to match rows using primary or unique keys, but this table has none; so it resorts to trying to match every single column value.
Again, this bring up the floating point issue. Matching floating point columns is very difficult due to the arbitrary precision and internal representation.
The best solution for this is to add a (non float) primary key for this table. It is also good practice.
If this is not an option you could try converting the problematic floats to decimal type. Decimal types do indeed match precisely across versions and platforms.
Check out this link for more info about the problems of matching floating point values:
http://
Cheers,
Frank