Just a quick question, currently there is no support via llbgen Pro for providing the ability to call a self reference a table. In my case I have a table which represents a company, a company can have business units, business units can have products and products can have releases. All of which is represented in a hierarchical format. If no support for self referencing tables is this considered to be offered in the near future. Also, would the best approach be then just stored procedures accessed via llblgen Pro? Thanks for any insight.

Eric

is that hierarchy all in the same table? If so, yes this is supported in Adapter, via a custom entity factory class.

Yep, the organizational structure is all in one table. Cool, so the adapter will support this. Is there any example in the docs when I attempt to use the adapter. I haven't played with it yeat as I'm still getting used to and testing the self service stuff.

I think I misunderstood you, read on

erichar11 wrote:

Yep, the organizational structure is all in one table. Cool, so the adapter will support this. Is there any example in the docs when I attempt to use the adapter. I haven't played with it yeat as I'm still getting used to and testing the self service stuff.

This is called supertype-subtype flattening, thus you have a supertype Employee, a subtype Manager and another subtype Clerk and Manager can have a subtype CEO. These are all stored in the same table with an extra field 'EmployeeType' which flags what type the EmployeeRow really is (employee, clerk, manager, ceo).

It's briefly discussed in the documentation of adapter. Basicly it's coming down to this: - you have a base entity which contains all teh fields of the table, you get this one from the generated code, in this example 'Employee' - you create derived classes from this entity: Manager, CEO and Clerk. - you create a derived class from EmployeeEntityFactory and override the Create(IEntityFields2 fields) method. This method will now no longer simply create a new EmployeeEntity() but will create based on the EmployeeType field's value a new Manager, CEO or Clerk instance.

So what you're doing is something else. I really fail to see why you've stuffed all that data into a single table, I mean, why is 'product' in the same table as 'company' ?

I have the same problem, I want to include a table twice in a relations collection, like in SQL when you include the same table twice, via an alias i.e. :

From Workorder join Task as taskA on Task.WorkorderId = Workorder.id join Task as taskB on Task.TaskId = taskA.id

So let me see if I can clarify things a little bit here. The result of this is nothing more than an organizations structure that will populate a tree control. Anyway, the idea would be that when a user clicks on one of the tree nodes, the right hand pane would display all of the appropriate modules. So for example, depending on what node (using your ex., Employee, Manager, Clerk) different modules would be populated on the right side pane.

So what you're doing is something else. I really fail to see why you've stuffed all that data into a single table, I mean, why is 'product' in the same table as 'company' ?

Well, I don't believe I'm really doing anything much different than what you suggested with supertypes/subtypes. I'm not attempting to stuff product and company entites into the same table. These are infact to seperate entities. In general, the org table consist of the following:

OrgId, OrgName, OrgParent, OrgType where the orgParent would reference the OrgId of it's parent and OrgType would specify the reference to the assoicated entity. No detail info of product or company would be present, that's where the OrgType comes in.

It's just I need a way to build an organizational structure which consists of references to the product and company entities.

(Wow, I may not be wording this as correctly as is possible).

Which is why your purposed method of using supertype and subtypes seems like it might be a good solution. Comments?