[This topic is migrated from our old forums. The original author name has been removed] [Attachment has been removed.]
When using the Compare Objects tool, I noticed these issues:
- the tool crashes with a *java.lang.NullPointerException* error when the "Flip" button is pressed more than once (as far as I see, only if the two objects are different). This happens both in Text and Grids mode.
- whatever the values, the tool marks as "different" two columns with different names; am I supposed to use an alias for each column? +(screenshots 1&2)+
- when comparing datasets from different technologies, two columns are marked as different even if their names and their values are equal. In this case, the columns from DB2400 are treated as *JDBC INTEGER (type 4), Java: Integer*, while the columns from Oracle are treated as *JDBC NUMERIC (type 2), Java: BigDecimal* +(screenshot 3)+. Would it be possible to make the comparison in a "smarter" way, maybe trying some kind of datatype conversion and allowing the user to enable/disable this feature?
I've also tried to upgrade the JRE from 1.6 to 1.7 (referring to [this |http://www.dbvis.com/forum/thread.jspa?messageID=15728㵰] thread), but nothing changed
Thanks in advance
Thanks for your feedback.
The NullPointerException for Flip is a known issue that we will hopefully get fixed in the next maintenance release.
Currently, the column names must be the same between the two tables. I'll add your vote for making it possible to manually map columns in one table to then columns in the other. One table may have additional columns, but all shared columns must have the same name in both. What you see is the result of interpreting columns X and Y as being added to one table while QTY and AMOUNT are seen as being deleted from the other. Added and deleted columns are not considered when calculating the number of changes, which is why it says "No change" in the status bar.
To get a really meaningful result, both grids must currently also have one or more columns as Primary Key. If not, all columns are considered to be key columns and a difference in any column value (with matching names) results in one deleted row and one added row. That's why you get the result you get when the data type differs for the QTY columns. We have on the todo list to make it possible to manually specify which columns should be used as key columns.
I'll open a ticket for looking into doing a "least common denominator" comparison for numeric values so that Integer and BigDecimal values can be compared.