>>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.

Good information. I'm trying to get my head around also how to effectively use the snapshots. I see that I might have 4 possibilities after a change:

1. Structural changes to database/tables/views/indexes.

2. Structural changes as above, plus updates to data during the upgrade.

3. No structural changes, but business rule changes that require updates to data.

4. Difference in data snapshots (delta) due to user data changes.

With testing, I need to get good sample data that takes into account our standard test cases, plus any new ones based on structural/business rule changes.

I'm trying to develop a sophisticated tool that will require minimal manual coding between snapshots. For getting new test cases, I know I will need to code into a script (or something like one), but for most everything else, I want it to handle it fairly routinely.

I see this mostly as a SQL-heavy app, but I would love to hear from anyone who has any ideas.