>>I am not sure you can do what you want using SQL.
>**You may be right! I just thought using CURSOR was an idea.
>
>>For one thing, I think you should have an extra [logical] field in both tables which is set to false for all records in both tables initially. Next, start a full table scan on one table then switch to the second table to start field comparisons among matching POs. Where you find matching records, set the flag fields in both to true.
>**Yes, I thought of this. I am poor in how to use SCAN, even FOR...ENDFOR. I am just good at DO WHILE...ENDDO and DO CASE...ENDCASE. I have done a VERY VERY LONG IF...ENDIF with MANY MANY IF...ENDIF within and just found out all can be done with one line of code!!!! Man!
>
>>The records left with a value of False will be the ones you need to reconcile. Because you have the potential of a many-to-many relationship, doing this relationally is of little help. Where it will help is when 1 record exists in one table but not the other.
>**I will study this...
>
>>The other problem is you do not have any way of uniquely identifying records that may have been matched up the previous time but do not exactly match this time. If at all possible, you are going to be better off enforcing a unique [key] field in the Excel source that you can carry over to the History table. If you do that, and get your History table synced with the Excell data, updates will be a breeze.
>**Can you explain little more here? I am trying to learn all possibility.

If you enforce a business rule in Excel where anytime a new record [row] is added to the Excel sheet, the next integer ID is entered. This means a new column needs to be added to the sheet fo this unique integer number. The next time you compare records, you automatically add to the history table any records with IDs that do not exist in the history table. Then updating existing records is simplified by relating the 2 tables based on the unique integer field. Your History table would also need this integer ID field as a Foreign key. You might also consider another field for its own Primary key.

With a Primary key and a Foreign key in the history table, you could then deal with a parameterized view of the history table. The parameter used would be the PK value of the parent [Excel] table. In the view designer, this would be a filter which would appear in the WHERE clause -- HistoryTable.ForeignKeyFieldName = ?nKeyID

Then, before you open or requery this view, you would initialize the ?nKeyID parameter to the value of the primary key in the parent table. The view would then only have the records from the History table that matched the PK value from the parent table.