>By data changes, I'm talking more of structural changes to the database. Sorry I didn't clarify that. My tool needs to work on the data in the tables as they exist at any given snapshot. These snapshots will happen at any time there was a structural change, or a significant/complex change to the code. It will be a way for us to make sure that the change has only the affect that we expect. It's kind of vaporware in my mind right now, so I'm definately open to all suggestions. For keeping up with the actual data in the tables, I do like your idea of tracking only the field-level changes rather than logging all fields at the record level, which is more common.

If it is for transferring data to a new structure (a frequent requirement), an APPEND FROM will copy all fields that have the same names. Watch out for RI: you have to copy the parent table (in a relation) before you copy the child table.

To compare fields, afields(), of course, will copy the field names into an array.

Another - perhaps better - option is COPY STRUCTURE EXTENDED, which will create a table which contains your structure. From there, it is much easier - compared to the array - to create a subquery, for instance, that lists fields contained in one structure, but not in the other one.