I've had those days. I guess to do what you're talking about, you'd have to have some function that would look through each table using he FCOUNT and FIELD functions (or AFIELDS) to build the SQL statement. But it would have to build the alternative value in NVL based on the data type of the field (NVL(Field1, "") as Field1, NVL(Field2, .f.) as Field2, for instance). And it would have to do something with field name conflicts. And how would it really know how to join the tables unless it could find some relationship info in the DBC? This would be a nontrivial task, I imagine.


>Yeah, it's been a brain dead day. Don't know what I was thinking. (Actually not thinking). Actually, I was wondering about generic code that would actually join three tables and avoid nulls using nvl() on all the fields, etc.
>
>:o)
>
>
>>select table1.*, table2.*, table3.* from table1 join table 2 on 1_to_2_join_condition ....
>>
>>You can probably figure out the rest. This is a start. Will it work for you? Are you saying you want the code so generic that it can join any three given tables in a parent-child-grandchild relationship?
>>
>>When ya gonna get rid of that fuzzy picture? (I can't talk - I've never submitted a picture <g>)
>>
>>>I have one parent table and two children. I want to create one table with the fields from all three (for a report). Is there an easy way to do this without hardcoding the fieldnames?
>>>
>>>For example,
>>>
>>>Parent table = table1
>>>1st child = table2
>>>2nd child = table3
>>>
>>>use table1 order tag site
>>>use table2 in 0 order tag site
>>>use table3 in 0 order tag site
>>>
>>>sele table1
>>>set relation to site into table2
>>>set relation to site into table3 additive
>>>set skip to table3
>>>
>>>Instead, I want one cursor with the fields for all three so I can use it in a report easier.