George,

>>* provided lnSize1 and lnSize2 are equal
>>if !llorder then
>>   =asort(Aflds1,1)  && sort on column name
>>   =asort(Aflds2,1)  && sort on column name
>>else
>>   * order matters so don't sort the arrays
>>endif
>>llMatch = .T.
>>for lxx = 1 to lnSize1
>>   for lyy = 1 to 16
>>      <b>if !(Aflds1(lxx,lyy) == AFlds2(lxx,lyy))</b> then
>>         llMatch = .F.
>>         exit
>>      endif
>>   endfor
>>   if !llMatch then
>>      exit
>>   endif
>>endfor
>>
>>return llMatch

>Larry,
>
>Just looking at it...not really. I'd SET EXACT ON to be sure is one thing (which I'm sure you'd do, just didn't include here).

I had actually forgotten about this. Thanks for reminding me. If alias1 has a field named THISISAFIELD and alias2 has a field named THISISA, this code would return it as a match. See change above in bold.

>I wouldn't necessarily compare all the elements. I mean I certainly wouldn't consider the tables different if the comments associated with the field were different. Would you?
>

Actually I would. I like putting comments in for fields for the simple reason that my field names are not pneumonic enough for some. I hate to type so smaller is better. The comment can tell the developer what the field is for and I only have to type that once. When Intellisense becomes a reality maybe I'll change my tune < s >.

>As I said initially, the solution depends largely on how "the same" is defined. Given the loose typing of VFP, you could say that numeric fields with the same field name, but different data types were "the same" (floats and doubles, example).

I see your point here. It would be in the mind of the developer. A purely VFP solution may ignore this type of thing while someone upsizing to another backend may want an exact match.

Regards.