Hi,

I'm working with a demo version to evaluate the foxfire product for purchase (version 8) (we've been in contact before but it's been a few weeks!). I have a question about data relationships.

It seems that you specifiy the relationships between tables when setting up a new report set - and the reportset will then support multiple requests within it. Our plan is to create a report set for all of our tables and deploy it to our users with the data dictionary nicely completed - the users will then add their own reports to the sample ones that we'll supply.

It seems like you set up the relationships between tables at the report set level -which makes some sense to me - however the way the tables relate will vary depnding on what info you're trying to retrieve - i.e. the user needs to be able to change the join conditions for each request. I can't figure out how the user does that - do I need to switch on a preference to display a joins tab on the request editor?

thanks in advance

craig

Thanks Andrew, found the button, just what I was looking for. I like the visual inner/left/right outer join display too.

Regards

Craig.

There is another option that Andrew didn't mention. 

The Expanded Search function allows an end user to widen or narrow a search on essentially the same criteria, I beleive Craig was asking about how to offer completely different relationships between the same tables, which could vary from one Request to another, all within the SAME report set.

This can be accomplished with a different Foxfire! feature called the Foxfire! View. The sample application that comes with FF contains an excellent example of this (choose the Help About option from the system menu and click "Demo File Relationships". You'll see a pictorial representation of how this works): 

In the example, the regular car broker business relationships are described as follows (and the intial illustration depicts this):

The car broker buys a car from a dealer, and refurbishes it incurring one or more expenses along the way. Then he sells the refurbished car back to a dealer (it can be a different dealer or even the SAME dealer he originally bought it from).

(A depiction of the alternate relationship can be viewed by clicking the button that says "Demo Use of Views. Be sure to read the text and then click OK to see the depiction of the alternate relationship). In plain English, the alternate relationship is this: the broker sometimes uses certain  dealers from the dealer table to perform the repairs. He may want to know which dealers are givng him the best turnaround or lowest prices to perform specific types of repairs.

To study the dealer performance with respect to repairs (i.e. which dealer made a particular type of repair in the shortest time or at the lowest cost),  we need an alternate relationship direclty between expenses and dealers. We also need to cancel the regular relationship between cars and dealers in order to avoid erroneous results.

By doing this, we have created a second set of relationships between the same tables. The two views are the usual "inventory" view and the alternate "expenses" view.

Both are both supported in the same report set. When set up correctly (which Andrew can explain far better than me), as the designer goes to create a new Request, Foxfire! automatically prompts him with an additional dialog that asks which view he wants to use (Inventory or Expenses). Once he chooses a view, Foxfire! presents the data items and relationships in the Specify Filter tab in conformance with the selected view, and performs the query correctly. And the user never needs to know anything about joins, relationships, or how they are accomplished.

Craig, I hope this answers your question and doesn't confuse you. It's a very sophisticated capability - one that addresses one of many teeth-gnashing challenges of modeling the real world in a relational database. But I wanted to respond to what I thought you were really asking, and also unearth this capability.

Cheers,