>>Thanks... I will look at these approaches. Also, we would love to see SDT support remote tables, so we would just have to look in the data dictionary for this info.
>
>That's on the drawing board right now (I was tempted to mention in my last reply that using SDT would be the perfect place to store meta data about your remote objects, but then I didn't <s>).
>

Are you saying I could maintain meta data for the remote tables in 5.1? I assume I would have to code it myself?


>Yes it does, and yes, that's definitely something you'd want for the remote data.
>

Certainly... I would like SFQuery to present all of the related tables to the user... for example... my employee master is linked to a job codes table, but, the user doesn't know what the ID/Identity of the job codes are, they just know the codes...

I would love to see SFQuery build the field list using meta data, removing the FK fields and replacing it with the field names of that table, for example...

it sees that hr_job_rule_id in ee_master is a FK to hr_job_rule, so hr_job_rule is added to the field list for the user to query.

This should happend whether using local or remote tables automatically... if lUsePersistentReleations is .t. of course.

Does this make sense?

BOb


>cAlias is the "main" table. Although there really isn't a "main" table when doing a SQL SELECT, we use cAlias as the starting point when determining what tables may be in a query. If lUseTemporalRelations is .T., we start from cAlias and look at the temporal relationship tree from there. If lUsePersistentRelations is .T., we start from cAlias and look in the DBC for the persistent relationship tree from there. Of course, for remote data support, we'll look in the meta data rather than the DBC.
>

It seems that, you are not including the tables unless they are open. Also, as I said, there is no join info in SFQuery... so, lets say I have a view of ee_master, and I want to user to be able to specify a filter... They may want to see all employees that have job code 'AC-123'... well, unless the join is included in the cFilter, how do I know they are using fields from the job codes table for the query?

Thanks for the great info...
BOb