I’ve been showing how I use intersect and the symmetric difference to compare data in two datasets. What’s nice about these approaches is that they are extremly flexible. You can, for example, pick just a few columns to compare from each table. So if you had two similar tables, you could easily detect which primary key + select attributes are either in both sets or not in both sets, returning the result into a third table or cursor. I’ve used these techniques in the following scenarios:
- to build master lists from client tables
- test code changes (run a procedure once, save the results A, make a code change, save the results B, compare differences)
- for data integration projects, especially for Changed Data Capture (CDC or incremental update) operations
- to check the status of metadata
- to do some down-and-dirty comparisons between two or more tables
Sys(2017)
One limitation of the SQL approach that I’ve been demonstrating is that you need to use a GROUP BY clause, which insists that you identify each attribute used in the select list (true for VFP, T-SQL, and other ANSI compliant SQL-enabled languages). This can be a lot of work, especially if you have a handful of tables with dozens of attributes.
The solution? Use a CRC (Cyclical Redundancy Check):
SELECT p_key, crc ; FROM (; SELECT p_key, PADR(Sys(2017, '', 1, 1),10) as crc FROM CursorA; UNION ALL ; SELECT p_key, PADR(Sys(2017, '', 1, 1),10) as crc FROM CursorB; ) AS tmp1 ; GROUP BY p_key, crc ; HAVING COUNT(*) = 1
SYS(2017) will Return a checksum value based on each row in the table. The second parameter is an exclusion list of attributes that you do not want included in the algorithm. The third parameter is the seed value, ignored when using the CRC32 version of function. The last parameter allows you to set flags to include memos or to use the CRC32 algorithm. In my example above, I am using CRC32 without memo support.
The resulting table shows me the primary keys that intersect (when HAVING COUNT(*)=2) or do not intersect (when HAVING COUNT(*)=1).
I hope you find this useful!
PS: It’s worth noting that you should avoid SYS(2017) in FoxPro versions 8 and below. There is a memory leak (fixed in VFP9) that could crash your app!
#1 by bill drew at October 6th, 2007
| Quote
We met in Atlanta.
sys(2017) very interesting
Your work has been helpful to me in my work at preparing sets of manufactured vehicles along with their values.
Keep it up, Todd