Okay, hopefully I haven't boxed myself in here. I have three files with the following relationships.

1. [Customers] --> 1 to many with [Publications]

-- linked with Customer_ID --

2. [Publications] --> 1 to many with [Options]

-- linked with Publication_ID --

3. [Options]

I'm printing a report using a layout that I created in [Options]. Inserting information from either [Publications] or [Options] is no problem. However, the only way that I can include information from [Customers] is to add a [CustomerID] field, relate [Options] to [Customers] and physically enter in the Customer's ID number in the [Options] file. So here are my questions.

1. Is there anyway I can enter the Customer_ID automatically?

2. Is this the right place for the report, assuming that I want to include data from all three files?

3. Is there an easier solution?

Thanks

- Kelly

In Options, create a relationship (many-to-one) with Publications, based on the same Publication_ID field. Since Publications already contains the Customer_ID field you want, you can bring it in directly as Publications::Customer_ID.

Incidentally, this allows you to create sub-summary reports, broken out by Customer_ID and Publication_ID (two sub-summary parts, of course), but I'm just rambling here.

When creating a new document in a related one with a one to many relationship how can I automatically enter the Customer ID number that links the two.

Right now, I'm copying and pasting this number. I've got beleive there's a better way.

Thanks,

Kelly

Not sure what you mean by "When creating a new document in a related one", since you're actually creating new records, but ploughing ahead anyway...

Assuming all the records in Publications can also be seen in a portal in Customers, since they're related by a common Customer_ID field that is unique in each record in Customers,

and

Assuming all the records in Options can also be seen in a portal in Publications, since they're related by a common Publication_ID field that is unique in each record in Publications,

Create a relationship from Options to Publications using the same Publication_ID fields. That way, in each record in Options, you can show the related info that already exists in Publications. Since each record in Publications has a Customer_ID, you can show that info in Options without a portal; just put a field on the layout that shows the related field Publications::Customer_ID. You can sort on this field in order to create sub-summaries, perfom finds, etc., just as if it were a resident field in Options.

Thanks danjacoby,

I'm not using portals, but instead using individual linked files. So when I create a new record I have to tell FMPro that that's what I want to do. I have a script that does this but in order to link everything properly I have to physically copy the Customer_ID from the [Customers] file and paste it into the [Publications] file. I also have to copy the Customer_ID in the [Publications] file to create a link to the [Options] file.

What's the easiest way to do this without portals?

Thanks,

Kelly

quote:

---

Originally posted by kcrossley:

Thanks danjacoby,

I'm not using portals, but instead using individual linked files. So when I create a new record I have to tell FMPro that that's what I want to do. I have a script that does this but in order to link everything properly I have to physically copy the Customer_ID from the [Customers] file and paste it into the [Publications] file. I also have to copy the Customer_ID in the [Publications] file to create a link to the [Options] file.

What's the easiest way to do this without portals?

Thanks,

Kelly

---

Quite seriously, if you don't have portals then the easiest way to do this is to create portals. That way, the *_ID field will auto-enter in the related record.

Not to mention the fact that, if you're not used to portals, it will open up a whole new range of abilities for you.

Frankly, while there are ways of accomplishing what you want without portals (I've thought of two), they're all extremely kludgy not only to program, but also to execute. Portals are clean, clear and easy.

Hi danjacoby,

Okay if I were to switch to using portals, which file would you use as the main file?

Thanks,

Kelly

See the answer in the "Automatically Entering Data" thread.