>Hi All,
>I want a sanity check. How many of you have tried this?
>
>Open a database. Instead of using ADBObjects() to query the DBC, use SQL to do the same thing while the DBC is already open.
>
>Run the following code:

>open database (home()+'\samples\tastrade\data\tastrade') shared
>use (home()+'\samples\tastrade\data\tastrade.dbc') again alias dbc_tastrade shared
>select objectname from dbc_tastrade where parentid in ;
>   (select objectid from dbc_tastrade where upper(objectname) = 'CUSTOMER' ;
>      and upper(objecttype) = 'TABLE') ;
>   and upper(objecttype) = 'FIELD'
>use in dbc_tastrade

>The above query circumvents having to open the customer table and issuing an AFIELDS() on it simply to get a list of fields.
>
>Because the DBC is simply another table, this makes sense. It's just something I have never tried (before today).

"Hacking" the metadata - getting information from the underlying table - is often used to do modifications for forms or reports, in cases where the built-in editing tools fail.

In this case, even if your method gives correct results, I would prefer ADBObjects(), because MS will try to keep backward-compatibility for ADBObjects(), but not (necessarily) for the table structure. That is, although it doesn't seem likely to me, your code might fail in VFP 8 or 9, because of some change in the fields.

Hilmar.