Anybody know the process or sequence by which VFP verifies a DBC to a DBF?

When you USE a table that's owned by a database container, VFP Help says that "VFP tries to confirm that each field of the table has a matching field object in the database." If not, you get Error 1984 saying "The fields in the table ... did not match entries in the database."

What I'm trying to figure is this:

   Does VFP walk through entries in the CONTAINER first
   then lookup the container's field reference in the TABLE

   -or-

   Does VFP walk through the TABLE first 
   then look for a reference to each field in the CONTAINER?

I realize this is somewhat trivial but I'm trying to explain it to someone else and inquiring minds want to know. The error message seems ambiguous to me since you get the same error message whether you USE the table or if you VALIDATE the DATABASE instead. I guess it's just wording, but the resolution is that you either (a) replace the DBC or (b) replace the offending DBF. To that goal, the message isn't all that helpful.

It seems that if you're "validating the database," you'd expect to read something like "Database is invalid BECAUSE it contains reference to a field that is NOT in the table it's evaluating." In this manner, you'd know which was out of whack: the DBC or the DBF. Rather, the message reads "The fields in the table ... did not match" which suggests there's something wrong with the table when in fact, the DBC could be out of whack.

If anyone out there has a more bullet proof of interpreting this error message, could you share it with me? Otherwise, I'm playing this guessing game that entails validating the DBC then looking at the DBF that's reported to be a problem. If the field IS there, then I know the DBC is wrong ... but ... if the field ISN'T there, then the DBC's out of whack ... How'd the DBC get out of sync in the first place? Me thinks indiscriminate dragging and dropping following programmatic ALTER TABLEs. Thanks.