It seems you never got an answer to this.
How did you work around it?
I currently have a reproducable method of getting this error.
I have a dataset I am pulling in from ODBC 252 fields and 1800+ characters in length per record. with 5 records.

I can use any of the following to get the error
copy to (filename) database (dbname)
dlnFields = afields(dlafields) -> create table (filename) with array dlafields
copy structure to (filename) database (dbname)

I am building a nightly process to acquire information from an ODBC source, for quicker more specificly indexed reporting.

I know this has been nearly a year since you encountered this, and maybe someone else could jump in, if they have any suggestions.

Thanks

Tracy


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