Our development team modified the table in one SQL database. The original table has three columes. Now, one of these columes have been divided into two columes. But they worried that data will lost in the new table. I get a task to test whether the data in the new table is comsistant with the old one. How can I do the test?? Can some testing tool do this kind of testing??
Please help me, it is ******!! thank you very much.
You could write queries for both before and after, then compare the outputs of both queries.
Bonus Tip! [img]images/icons/smile.gif[/img]
Based upon the description of the change - splitting a column, you might want to investigate the "why" behind the change. The "why" may lead to some changes in practices. Why? I am wondering why a column would need a split. Should not a proper db-design effort have prevented this need? Was there short-sightedness involved here? If the investigation data show that this is a shortsightedness issue and could have prevented; then one could make a strong case for upstream process/practice change.
Does the split involve keys? Do any of the new columns involve keys? Are there batch processes impacted by the change? If "yes" to any of those questions, then the magnitude of the validation task increases dramatically.
meggiewl, the asterisks in your post tell us that you felt that your problem was important enough for us to drop what we were doing and answer you. You were lucky to get the responses yoou did, when you did! Don't use that "******" word again!
Apparently you have both the old and new tables available to you. And I assume you know the logic used to split the one column into two.
Based on that, if the rule to recombine the columns is simple (like concatenation), then a query joining the two tables will do what you want. If you need help with that, I recommend you ask someone in your organization who is fully familiar with SQL.