Hi Bob.

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

>Does SDT hold persistent relation info? Or, it doesn't due to it being in the .DBC? For remote tables this is a item we would have to store.

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

>Can you briefly explain the difference between .cAlias and .aTables and how they are used when creating this .cFilter string?

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.

aTables is for when neither lUseTemporalRelations nor lUsePersistentRelations fit the bill. Here, you specifically name the tables you want involved. That way, just because a table is related to cAlias doesn't mean the user will get to filter on it.

Doug