Table CC has a portal from table CCL (L=line item table) that pulls info using pulldown lists from

Table P and Table S.

Then Table L has a portal from table LL (L=line item table) duplicating (most of) portal from Table CC

Workflow of above is create record in CC once that is established you move onto Table L and Create that record from where you create a report or invoice of combined info.

ALL ABOVE WORKS FINE so I would think that my relationships are ok!

Needed to add another field in CCL table to set rate for each record (this field is a percentage value list).

This rate has to be used in conjunction with a Fee field in Table L to find the commission.

Now in Table L when I bring this field in the portal I can change the rate here as I should but it only changes the first records rate and duplicates that rate for all records all down the portal and does not change the rate in Table CC.

Tables CC and L should be able to edit this rate field in either tables portal.

The other problem related to the above is a Cancel checkbox in the same portals as above that allows the user to temporarily omit a record from a report or an invoice. If I use ConstrainFoundSet in the script that creates the report or invoice it omits the whole record instead of the portal row.

Thanks

Fastest

****In trying to figure this out I found this in FMP7 page 175 (But I don't get it when I look at my file).

Repeating Portals:

Question: "I've created a portal, but instead of seeing a set of different records, I see that every single row of portal shows exactly the same date."

Answer: This indicates a mismatch of table occurences. Specifically, it suggests that although the portal is set to look at records from table occurence A, the fields you've chosen to display in the portal are actually from table occurence B. Because it's possible to have several different table occurences that are based on the same underlying table, it's possible to see the same field list for several different table occurences.

Nevertheless, if the portal and the fields displayed in it draw from different table occurences, you probably won't get a meaningful display, even if the different table occurrences are all based on the same

underlying table.

I am not clear what the table structure is here. you modified two table names CCL and LL with the (L is line items) are CCL and LL occurenecs of the same table or are they different tables? From what you have said I cannnot see a relationship between CCL and LL which would enable you to change a rate in one table and have it reflected in the other.

The behaviour you are describing in the portal does look like the rate field is in a different table occurence to the other portal fields.

On the final problem with regard to ConstrainFoundSet. It sounds as if you might be finding records in CC (or L) via a find on the portal. If that is the case then omitting a record from the found set will omit a record in CC (or L).

In trying to figure this out I found this in FMP7 page 175 (But I don't get it when I look at my file).

This exactly - is the toughest part to graps with 7, at least to me!! Fortunately does this video try to make it more comprehendabel:

http://www.filemakermagazine.com/freefiles/541/Graph_Rules.zip

--sd

Thanks for the reference I will study that. I found a most useful paper when I was first trying to get to grips with FMP7 was called "Key Concepts in Filemaker 7" by Michael Harris - not an easy read - but a crucial sentence right at the end caught my eye (and his, he calls it a Zen moment) "a layout is attached to a table occurrence not to a table". I think this observation is where the understanding begins.

http://www.digfm.org/ref/FM7_key_concepts.pdf

Hi SlimJim

CC, CCL, L, LL, P, S are all seperate tables.

The rate field is in the CC table and should also show in the L table's portal from the LL table.

Regarding the 2nd problem:

In the L table if I delete a portal record that comes from the LL table (selection is made from a pulldown list that is filtered to only show that particular catalog)

it doesn't delete it from the C table's portal which is from the CCL table.

I hope that clarifies it. I will check out your reference Soren, thanks.

Thanks

Fastest

Especially to a foreigner is an abbreviation a big problem, it generates unintended noise, because we often use the same letter sequences for entirely different entities ...couldn't you give your tables and table occurences a SAYING name instead!!!

--sd

Hi Soren

I thought I was making it simpler by showing the initial only

so here are the real names.

CC=Client Catalog, CCL=Client Catalog Line items, L=License, LL=License Line items, P=People and S=Stock.

hope that helps...thanks

I might be more stupid than the avarage roaming here, but I would like this to be added to the guidelines for posting!

--sd

I'm not sure what exactly your asking Soren, but I'd agree that using actual entity names is much easier to visualize than abbreviations, or the assorted varieties of "Table1, Table2" and "File A, File B" that we see. When I see these, I usually skip the thread or ask for real entity names.

However, this discussion probably doesn't help fastest with his/her problem.

Soren

If I knew it was a ridiculous request I wouldn't have posted it.

However if you can remember when your knowledge of FMP was closer to mine, then maybe you can see why I am asking. So I guess it's up to the forum to decide if it is only for the experts or they are willing to help the less informed.

Yes your right Ender and thank you for stating it.

Fastest

The poll is not about your request, but a poll to get this into the guidelines

However if you can remember when your knowledge of FMP was closer to mine

Especially back then was it important not to try to speak in jargon and abbreviations - Sounding like a IT journalist that never have programmed a single line of script/code doesn't encourage helpers to line up!

--sd

Ahem... The way I understood it, S

Which of course it is, since no one reads those...

ha... ha... Yes it is, but it makes it plausible to caution the sysops... Lee is excellent when it comes to "easy to understand" reprimands

--sd

I'm confused!!

Can you post a graph of your relationships??

You mention deleting a record from a table based on

another table's portal etc... confusing.

What is the relationship between Client Catalog Line & Licence Line??

Is the relationship setup to "allow to delete records"?

Dan

Hi Dan

I'm even more confused, but I am trying to temporarily (using a checkbox called cancel) OMIT a portal row (portal displayed in table L but from Table LL)from an invoice or report. I don't want to delete it, that I have set up already.

Regarding the first problem I mentioned: I am trying to

have the same field (rate field)from the CCL table which is displayed in the CC table, change the rate at the L table's portal which is from LL table.

As far as the relationship goes...I attached a jpeg

(I don't see it in the preview of my post if it doesn't show I'll investigate how to do it)

Is there an easy way to create a stripped down version of my file in FMP7 that I am unaware of? Other than manually copying and deleting a lot of stuff. Then maybe I could upload it.

Thanks for responding

Fastest

Forget the jpeg...

P table uses categoryID...to link to CC table (also using categoryID)

CC table using clientID...to link to L table (also using clientID)

L table using clientID...to link to CCL table using clientID

+

L table using LicID...to link to LL table (also using LicID)

I hope this is clear???

thanks

fastest

There isn't a rule about using file/field names. However, if I had my wish, the posters would use real names for things. If you want to short cut this a little, you can always put your abbreviations behind the first occurrence of the full name, using parentheses like this: [color:"blue"] Client Catalog Line items (CCL).

I think that it is easier to follow the post using real names instead of the File_1, Field_A, File_2, Field_X etc.

To me, I can concentrate on what the poster is asking, rather then trying to break their code.

Sometimes the responses can be tailored to the problem, making it easier for them to understand the response, and even copy and paste a calculation right into their file rather than having convert the response back to their own nomenclature.

My 2

Hi Fastest,

I'm coming late, and I only scan the thread, so forgive me if I missed something obvious here, or if it has already been suggested and answered. However, somethings these threads move faster to a close if you [color:"blue"] Attach a copy of your files, or at least a good replica of them.

It took me so long to compose my other response about the abbreviations, that it seems like everyone else stole my thunder.

Sorry, I didn't mean to step on anyone's toes.

Lee

Lee

Is there an easy way to create a stripped down version of my file in FMP7 that I am unaware of? Other than manually copying and deleting a lot of stuff. Then maybe I could upload it. It is such a mess now that I wouldn't want to do that to anybody.

Thanks for responding.

Fastest

File -> Save a Copy As {select Clone}

I know I am not Lee, but that hasn't stopped me yet!

Hi JT,

ROTFLMAO. - Yes Sir, I have missed your humor a lot.

Hi fastest,

Pretty doesn't count until the solution is ready for your users to see.

Lee

Hi Guys

sorry I couldn't answer sooner, but still can't.

Queue, yes I am aware of the clone, It's just that all else is a confusing mess.

Lee, thanks for your response.

Will get back to you guys ASAP.

Thanks

Hi Fastest

I am wondering if you mix-up layout & tables....

When you say:

....portal displayed in table L but from Table LL...

Do you mean you have a form based on table L that shows a portal?

And that portal is based on table LL??

If that is the case how are the 2 tables related?

Who / how do you decide the row(s) to omit??

To "hide" the portal rows, an easy way would be to add to your relationship

something like AND g_FilterOmit = t_OmitStatus

Create the global text field g_FilterOmit in your "base" table, create the

text field t_OmitStatus in your "related" table...

Put the value of "NO" in your global; put the default value of "NO" in every

record in your related table. When you decide to Omit a record

change the default to "YES" for that record. That way your

relationship will not find a match for that record.

HTH

Dan