Print Page | Close Window

Relationship Issue in reports

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce Classic
Forum Discription: For .NET 2.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=541
Printed Date: 14-Apr-2026 at 3:51pm


Topic: Relationship Issue in reports
Posted By: DataMan
Subject: Relationship Issue in reports
Date Posted: 08-Nov-2007 at 10:25am

In the tutorial Database you have the following structure:

So I want to create a devexpress report based on the “Area” object.

I want to show the Area.description, Territory.description and the Employee.LastName that is assigned to the territory and I don’t want to use a property to pull out the employees last name.

How do I do that without creating a view or stored procedure?  The field list stops at Area.Territories.EmployeeTerritories.EmployeeID

 
In SQL I would just write the following query:

SELECT     dbo.Area.Description AS [Area Description], dbo.Territory.Description AS [Territory Description], dbo.Employee.LastName FROM         dbo.Area INNER JOIN dbo.Territory ON dbo.Area.Id = dbo.Territory.AreaId INNER JOIN  dbo.EmployeeTerritory ON dbo.Territory.Id = dbo.EmployeeTerritory.TerritoryId INNER JOIN  dbo.Employee ON dbo.EmployeeTerritory.EmployeeId = dbo.Employee.Id

Which returns (list edited for size):

Eastern

Wilton

Eastern

Neward

Eastern

Westboro

Fuller

Eastern

Louisville

Fuller

Southern

Atlanta

Leverling

Southern

Savannah

Leverling

Southern

Orlando

Leverling

Eastern

Fairport

Buchanan

Western

Phoenix

Suyama

Western

Scottsdale

Suyama

Northern

Minneapolis

Dodsworth

 

I could create a class for the stored proc and then report on it but that is very ineffective for me as I have 3 different databases I am hooking up to.  Problem is if I need to make a simple addition to the stored proc it means modifying the stored proc, rebuilding all 3 models and then creating a upgrade script for the 300 users to update their databases.

Any ideas?
 
Thanks



Replies:
Posted By: GregD
Date Posted: 09-Nov-2007 at 2:11pm
The relationship between Territory and EmployeeTerritory is one-to-many. That makes it impossible to identify a single Employee associated with a given territory.


Posted By: Linguinut
Date Posted: 09-Nov-2007 at 4:36pm

What about querying the EmployeeTerritory rather than Area?

String mLastName = EmployeeTerritory.Employee.LastName;
String mAreaDesc = EmployeeTerritory.Territory.Area.Description;
 
If necessary, you can add subqueries to limit the data by Area and such.
 
Bill


Posted By: JeeZ
Date Posted: 21-Nov-2007 at 3:02pm
Hi,
 
I have a similar issue. I assigned my binding source to the report, but I can't drill down the "contact" on the field list (left side of the picture), even if I can in the Data Source (right side of the picture). It's a one-to-many relationship (a contact can have 1 or more bilan, linked by the foreign key ContactID in the Bilan table). Therefore, every Bilan as only one Contact.
 
As you can also see, I have a many-to-many relationship with "codes", which is working fine.
 
Note that the bilan object is working fine on my grids and my other forms, I only have the problem in the XtraReport. Is there a way to manually configure the field list?
 
 
 
 


Posted By: GregD
Date Posted: 26-Nov-2007 at 2:46pm
The ability to navigate down hierarchies of nested properties depends upon deep support of the .NET interface ITypedList. Basically, components that are seeking information about the properties available for binding on a type must ask the list that contains instances of that type, rather than reflect upon the type itself; and if nested properties are to be expandable in a tree, the component containing the tree must iteratively walk through the relationships.
 
The XtraReport field list does not appear to be implemented to do this properly.  You should still be able to bind to nested properties using techniques shown in the Reporting tutorial, but I am afraid you will have to take the issue of the behavior of the XtraReport field list up with Developer Express.
 
Best Regards,
Greg Dunn
IdeaBlade
 



Print Page | Close Window