Database Table Checkpoint issue
Hi all,
I am having an issue with DB checkpoint, on some values it complaints in the log that the values are different even though they are not.
E.G The "BeginChainage" field of row 2 contain...
Forum Discussion
Most likely the problem is that the data in your SQL table has more significant digits than what is "stored" in your database checkpoint. So, while the data may LOOK the same in the log, there is a difference.
I'm honestly not sure how to overcome this as I don't use Database Table checkpoints... I create my own SQL comparison routines because, more often than not, the data in my SQL is dynamic enough that a "static" table checkpoint just doesn't work. You might want to consider the same so you can account for these kinds of differences.
Hello,
Thanks for sharing your knowledge.
I am ok with "static" comparison as it does now, because our intension here is to verify "apples to apples", and it work fine when both DBs are identical, no mater how many rows/columns it is!
But when it's not, it shoots me bunch of records that are incorrect along with those that are correct (but it still says that it's not, E.G. 25!=25) which is anoying.
If you coud share some info with me on your approaches for DB data comparison that's would be nice :)
I use the ADO objects in TestComplete to build my own SQL queries and return a record set. I then have a baseline of what I'm looking for stored in a CSV file. I loop through the record set and compare column values per record with column values per row in the CSV file. It allows me to be very specific in my queries, allows me to format and trim values, and all sorts of stuff like that.
Now, that said, I THINK Data Table comparisons like you're doing allow you to alter the SQL query used. You might want to consider writing a custom query instead of using the default to "cast" values or trim them or round them or whatever.... what you're experiencing, as mentioned, is that the data table stored values only store up to a certin number of digits...but the data in the SQL table itself is a float or something like that which may have additional significant digits that don't display. Doing a custom query allows you to do these kind of formatting to actually compare "apples to apples" rather than what's going on right now.
Thanks for quick reply and info shared.
I do use ADO objects, mainly to connect and and drop DBs after comaprison is done, I might consider using more of them.
Speaking about "built-in" feature for DB tables comparison, I always use SELECT * FROM table_name to avoid missing anything, and these tables are stored in TC project, so I know they are correct. Again, my goal is to verify let's call it an aggreagtion process with different versions of our software, and so nothing get's broken/missing and I suppose to get identical data all the time. If so, the whole process works like a charm, when tbl_abc = tbl_abc with a "clean" log after, when at least one cell is unequal, it inconsistently (sometimes that unmatched value only and sometimes more of those that are actually correct and equal) are populating the log. Well, at least it catches when I have at least one incorrect record, but with many other correct and incorrect ones! :)
