I created typed list in designer, using several entities that are related from the base (CgmBans) m:1

when trying to fetch the typed list my program kept on blowing up. After enabling tracing and looking at the sql I saw that none of the related tables were specified in the from clause but fields from them were in the select clause.

I looked to the help and saw that your sample showed filtering on "Brazil" but it first did and GetRelationInfo into the predicate bucket.

I didn't want to do any filtering so I just did the GetRelationInfo, this fixed the error.

If I build a typed list in designer from multiple related entities, why don't the relations automatically get expressed into the SQL from clause?

Guess I can't edit the subject line to fix my typos

arschr wrote:

I created typed list in designer, using several entities that are related from the base (CgmBans) m:1

when trying to fetch the typed list my program kept on blowing up. After enabling tracing and looking at the sql I saw that none of the related tables were specified in the from clause but fields from them were in the select clause.

I looked to the help and saw that your sample showed filtering on "Brazil" but it first did and GetRelationInfo into the predicate bucket.

I didn't want to do any filtering so I just did the GetRelationInfo, this fixed the error.

Correct. You first retrieve the relationpredicatebucket from the typedlist, and if you want to do any extra filtering, just add it to that bucket, otherwise move along and pass that bucket to the fetch code.

If I build a typed list in designer from multiple related entities, why don't the relations automatically get expressed into the SQL from clause?

Because the developer has now control over what's used for relations and filters, otherwise there would always be some relations present. It's a way to solve it, and it has pros/cons, another solution, where you could supply the filter and everyting else would be taken care of, would have been easier, but less flexibel.

What then is really "inside" a typed list object coming out of the designer?

It looks like it knows it's base entity and has a detached knowledge of it's default fields (in typedlist.GetFieldsInfo) and knowledge of it's default relationships (in typedlist.GetrelationInfo).

But since both of these are supplied to the fetcher not to object itself, what latitude do I have when providing field and relationship info to the fetcher? Can I provide the fetcher with any set of fields and relationships that are based from the base entity set in the designer? Or am I constrained to the relationships and fields I've set in the designer?

Also should there not be a convieniance overload of the fetcher that uses the defaults fields and relations set in the designer?

And shouldn't the designer allow building defaults for the other components of the typed list fetcher, such as the sort sequence, group by sort, allow duplicates etc.?

arschr wrote:

What then is really "inside" a typed list object coming out of the designer?

It looks like it knows it's base entity and has a detached knowledge of it's default fields (in typedlist.GetFieldsInfo) and knowledge of it's default relationships (in typedlist.GetrelationInfo).

yes, everything is available.

But since both of these are supplied to the fetcher not to object itself, what latitude do I have when providing field and relationship info to the fetcher? Can I provide the fetcher with any set of fields and relationships that are based from the base entity set in the designer? Or am I constrained to the relationships and fields I've set in the designer?

Yes you can. You can also expand (using the fields' Expand method) the fields list, to add a field for example, or perform operations on the relations collection, to specify join hints on the fly.

Also should there not be a convieniance overload of the fetcher that uses the defaults fields and relations set in the designer?

Very good point. I've flagged it as a must have feature (it's a minor addition) to the runtime libs/generated code for the current upgrade in development.

And shouldn't the designer allow building defaults for the other components of the typed list fetcher, such as the sort sequence, group by sort, allow duplicates etc.?

I've decided not to do that, as that would make changing such a parameter force you to use the designer again, regenerate code etc. The philosophy is that you provide that information when you need it, i.e. when you fetch the data.

Thanks.