New Posts New Posts RSS Feed: Relationship Issue in reports
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Relationship Issue in reports

 Post Reply Post Reply
Author
GregD View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 374
Post Options Post Options   Quote GregD Quote  Post ReplyReply Direct Link To This Post Topic: Relationship Issue in reports
    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
 
Back to Top
JeeZ View Drop Down
Newbie
Newbie


Joined: 14-Nov-2007
Location: Canada
Posts: 10
Post Options Post Options   Quote JeeZ Quote  Post ReplyReply Direct Link To This Post 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?
 
 
 
 
Back to Top
Linguinut View Drop Down
Senior Member
Senior Member
Avatar

Joined: 14-Jun-2007
Location: United States
Posts: 394
Post Options Post Options   Quote Linguinut Quote  Post ReplyReply Direct Link To This Post 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
Back to Top
GregD View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 374
Post Options Post Options   Quote GregD Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
DataMan View Drop Down
Groupie
Groupie
Avatar

Joined: 26-Jul-2007
Location: Canada
Posts: 52
Post Options Post Options   Quote DataMan Quote  Post ReplyReply Direct Link To This Post 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
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down