JimK 28184 (7/17/2015)
I will try to integrate that into what I have already to do a name check first. We do get some that would be like Id in one table and then OrderId in the other, that may match. A lot of times it'd be Id in one table and then Giraffe in the other (wild example, but really that the names mean nothing to one another).So the current logic is:
If names are close, or contain any name like the other table name, then it may be a match. If not, a singular unique column in the table should be the Key, if not, check the next most distinct column in conjunction with the first. Continue down the line until a unique value is found (only adding in column if it makes the previous try MORE distinct). Then check if those fields match up to any fields in the other table by data. Report if there is 90% or more certainty that it is a match.
Assuming you were to find guesses, then you could "test" your guess by checking whether the "TableTwoID" column follows the requirements of a "foreign key":
- that the data type is the same or compatible with the "ID" you think it matches up to
- that the values in "TableTwoID" all exist in table two's ID column.
You might need to make caveats around NULLs or some default value (e.g. 0).
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?