Relationship Issue

[Peter Kilcoyne]

Hi Folks:

I have a database "MarComProjects" and another "Parts". Table_Mail is  
in the "MarComProjects" db and Table_Parts is in the "Parts" db.

The relationship is Table_Parts  to Table_Mail via fields ProjNum in  
Table_Parts equal to ProjNum_job in Table_Mail AND Mail in  
Table_Parts equal to Mail_job in Table_Mail. Mail_job is a auto text  
field entered text field with the word "No".  Mail is a drop down  
list with the option of "yes" or "no". I have a portal in the  
"MarComProjects" that is set to view records from Table_Mail.

What I want is to view only the records of a set of projects that  
will mail, not all of the projects with the same ProjNum will mail.  
When I set this up I get the first project associated with ProjNum  
repeated 9 times in the Portal instead of the list of individual  
projects that make of the mail portion of the job.

I hope this makes sense and I hope you can point me in the righ  
direction.

TIA,
Peter

[Steve Cassidy]

Hi Peter

> What I want is to view only the records of a set of projects that  
> will mail, not all of the projects with the same ProjNum will mail.  
> When I set this up I get the first project associated with ProjNum  
> repeated 9 times in the Portal instead of the list of individual  
> projects that make of the mail portion of the job.

Hmmm... The usual reason for this kind of thing is wrongly defined  
fields in the portal. You must make sure that any field within a  
portal is specified via the same relationship (ie is from the same  
table occurrence) as used by the portal.

This can get a bit confusing if you have more than one relationship  
set up between a pair of tables; it's possible to choose the 'correct'  
field but from the wrong table occurrence.

So I'd say this is the first thing to check...

> I hope this makes sense and I hope you can point me in the righ  
> direction.

I must admit, it's a bit difficult to follow your setup mid-evening  
after a couple of glasses of wine. If the problem does not prove to be  
the above, I'll consider the situation a bit more carefully in the  
morning :)

Steve

[Peter Kilcoyne]

Thanks Steve, I do have the fields from the proper Table in the  
proper portal. Enjoy the wine.

Peter
On Oct 7, 2009, at 3:34 PM, Steve Cassidy wrote:

> Hi Peter
>
>> What I want is to view only the records of a set of projects that  
>> will mail, not all of the projects with the same ProjNum will  
>> mail. When I set this up I get the first project associated with  
>> ProjNum repeated 9 times in the Portal instead of the list of  
>> individual projects that make of the mail portion of the job.
>
> Hmmm... The usual reason for this kind of thing is wrongly defined  
> fields in the portal. You must make sure that any field within a  
> portal is specified via the same relationship (ie is from the same  
> table occurrence) as used by the portal.
>
> This can get a bit confusing if you have more than one relationship  
> set up between a pair of tables; it's possible to choose the  
> 'correct' field but from the wrong table occurrence.
>
> So I'd say this is the first thing to check...
>
>> I hope this makes sense and I hope you can point me in the righ  
>> direction.
>
> I must admit, it's a bit difficult to follow your setup mid-evening  
> after a couple of glasses of wine. If the problem does not prove to  
> be the above, I'll consider the situation a bit more carefully in  
> the morning :)
>
> Steve

[Richard S. Russell]

Some javascript/style in this post has been disabled (why?)

On 2009 Oct 7, at 14:37, Peter Kilcoyne wrote:

Thanks Steve, I do have the fields from the proper Table in the proper portal. Enjoy the wine.

Another problem similar to what Steve mentioned can arise if you're displaying a calculated field. If that's the case, go back to the definition of that field and look at the very topmost line in the calculation dialog box, where it says "Evaluate the calculation from the context of:" and make sure you're eyeballing it from the proper table.

Then there's the ridiculously prosaic question of whether the field is physically within the borders of the portal's top line.

[Peter Kilcoyne]

Some javascript/style in this post has been disabled (why?)

Neither field is calculated, both are text fields one with a drop down list yes/no and one with an auto enter "No". Both are within the borders of the portal. I suspect, but can't figure it out, is that it has to do with the relationship and how it is set up. But what is stumping me is why the Mail Portal list the same record 9 times instead of individual records.

Peter

On Oct 7, 2009, at 3:46 PM, Richard S. Russell wrote:

On 2009 Oct 7, at 14:37, Peter Kilcoyne wrote:

Thanks Steve, I do have the fields from the proper Table in the proper portal. Enjoy the wine.

Another problem similar to what Steve mentioned can arise if you're displaying a calculated field. If that's the case, go back to the definition of that field and look at the very topmost line in the calculation dialog box, where it says "Evaluate the calculation from the context of:" and make sure you're eyeballing it from the proper table.

Then there's the ridiculously prosaic question of whether the field is physically within the borders of the portal's top line.

[John Weinshel]

I'd go back to Steve's post and take another look. You replied that the
fields were drawn from the proper table, but are they drawn from the proper
TO? What you describe is commonly the result of using the wrong TO. 'Wrong'
means a different TO than the portal's (direct inline hops from the portal's
TO are OK).


John Weinshel
Datagrace
Vashon Island, WA
[phone]
Member, FileMaker Business Alliance
Certified For FileMaker 10
________________________________________
From: FileMaker Pro Discussions [mailto:[hidden email]] On
Behalf Of Peter Kilcoyne
Sent: Wednesday, October 07, 2009 12:47 PM
To: [hidden email]
Subject: Re: Relationship Issue

Neither field is calculated, both are text fields one with a drop down list
yes/no and one with an auto enter "No". Both are within the borders of the
portal. I suspect, but can't figure it out, is that it has to do with the
relationship and how it is set up. But what is stumping me is why the Mail
Portal list the same record 9 times instead of individual records.

Peter
On Oct 7, 2009, at 3:46 PM, Richard S. Russell wrote:



On 2009 Oct 7, at 14:37, Peter Kilcoyne wrote:


Thanks Steve, I do have the fields from the proper Table in the proper
portal. Enjoy the wine.


Another problem similar to what Steve mentioned can arise if you're
displaying a calculated field. If that's the case, go back to the definition
of that field and look at the very topmost line in the calculation dialog
box, where it says "Evaluate the calculation from the context of:" and make
sure you're eyeballing it from the proper table.

Then there's the ridiculously prosaic question of whether the field is
physically within the borders of the portal's top line.

[Steve Cassidy]

Peter

Is 9 the CORRECT number of related records? If so, I'd suspect a  
problem along the lines of the one I described.

If there should be some number other than 9 related records, then your  
relationship is likely set up wrong...

But then I've now had a further glass of wine. I could be wrong.

Steve


On Oct 7, 2009, at 8:47 PM, Peter Kilcoyne wrote:

> Neither field is calculated, both are text fields one with a drop  
> down list yes/no and one with an auto enter "No". Both are within  
> the borders of the portal. I suspect, but can't figure it out, is  
> that it has to do with the relationship and how it is set up. But  
> what is stumping me is why the Mail Portal list the same record 9  
> times instead of individual records.

[Geoff Graham]

On Oct 7, 2009, at 4:51 PM, Steve Cassidy wrote:
> ...

> But then I've now had a further glass of wine. I could be wrong.
...

One more glass Steve and you may attain true clarity.

Peter,

The line from the starting table occurrence (the layout) to the  
destination table occurrence (portal content) is not what your portal  
wants it to be. Now if you're sure the portal is set right, that  
leaves your relationship graph. It's one of the two right? You ruled  
out calculations evaluating from the wrong context.

I'd start troubleshooting by placing another (temporary) table  
occurrence in the graph that is what I think it should be, then bring  
a related field into an unused area of the parent's layout. I'd expect  
to see the first related child record's data. Then a simple 6 line  
portal over that. A serial field or some other identifiable data from  
the related records would be my choice. Kind of a take it from the top  
approach.

I've certainly fought this one before.

Geoff

[John Weinshel]

Peter,

I hope you write back to the list to let un know the outcome.


John Weinshel
Datagrace
Vashon Island, WA
[phone]
Member, FileMaker Business Alliance
Certified For FileMaker 10


-----Original Message-----
From: FileMaker Pro Discussions [mailto:[hidden email]] On
Behalf Of Geoff Graham
Sent: Thursday, October 08, 2009 5:38 AM
To: [hidden email]
Subject: Re: Relationship Issue

On Oct 7, 2009, at 4:51 PM, Steve Cassidy wrote:
> ...

> But then I've now had a further glass of wine. I could be wrong.
...

One more glass Steve and you may attain true clarity.

Peter,

The line from the starting table occurrence (the layout) to the  
destination table occurrence (portal content) is not what your portal  
wants it to be. Now if you're sure the portal is set right, that  
leaves your relationship graph. It's one of the two right? You ruled  
out calculations evaluating from the wrong context.

I'd start troubleshooting by placing another (temporary) table  
occurrence in the graph that is what I think it should be, then bring  
a related field into an unused area of the parent's layout. I'd expect  
to see the first related child record's data. Then a simple 6 line  
portal over that. A serial field or some other identifiable data from  
the related records would be my choice. Kind of a take it from the top  
approach.

I've certainly fought this one before.

Geoff

[Peter Kilcoyne]

John:

I will I am working on a couple of unrelated issues at the moment  
that are more pressing. But I'll be sure to reply, I value the Lists  
advice.

Peter
On Oct 8, 2009, at 11:53 AM, John Weinshel wrote:

> Peter,
>
> I hope you write back to the list to let un know the outcome.
>
>
> John Weinshel
> Datagrace
> Vashon Island, WA
> [phone]
> Member, FileMaker Business Alliance
> Certified For FileMaker 10
>
>
> -----Original Message-----
> From: FileMaker Pro Discussions [mailto:FMPRO-
> [hidden email]] On
> Behalf Of Geoff Graham
> Sent: Thursday, October 08, 2009 5:38 AM
> To: [hidden email]
> Subject: Re: Relationship Issue
>
> On Oct 7, 2009, at 4:51 PM, Steve Cassidy wrote:
>> ...
>
>> But then I've now had a further glass of wine. I could be wrong.
> ...
>
> One more glass Steve and you may attain true clarity.
>
> Peter,
>
> The line from the starting table occurrence (the layout) to the
> destination table occurrence (portal content) is not what your portal
> wants it to be. Now if you're sure the portal is set right, that
> leaves your relationship graph. It's one of the two right? You ruled
> out calculations evaluating from the wrong context.
>
> I'd start troubleshooting by placing another (temporary) table
> occurrence in the graph that is what I think it should be, then bring
> a related field into an unused area of the parent's layout. I'd expect
> to see the first related child record's data. Then a simple 6 line
> portal over that. A serial field or some other identifiable data from
> the related records would be my choice. Kind of a take it from the top
> approach.
>
> I've certainly fought this one before.
>
> Geoff

[Peter Kilcoyne]

Geoff, Steve, and John:

In my original database relationship Table_Jobspecs (MarComProjects)  
is related to Parts via ProjNum=ProjNum_job AND  
Constant=Constant_Job. I duplicated the same relationship and swapped  
Constant and Constant_job with Mail and Mail_job naively thinking  
this would work and changed the name (since you can't have two named  
the same) to Mail. This maybe where I went wrong.

Comments?

Also if I un-index the fields Mail and Mail_job nothing shows up.

Peter
On Oct 8, 2009, at 8:37 AM, Geoff Graham wrote:

> On Oct 7, 2009, at 4:51 PM, Steve Cassidy wrote:
>> ...
>
>> But then I've now had a further glass of wine. I could be wrong.
> ...
>
> One more glass Steve and you may attain true clarity.
>
> Peter,
>
> The line from the starting table occurrence (the layout) to the  
> destination table occurrence (portal content) is not what your  
> portal wants it to be. Now if you're sure the portal is set right,  
> that leaves your relationship graph. It's one of the two right? You  
> ruled out calculations evaluating from the wrong context.
>
> I'd start troubleshooting by placing another (temporary) table  
> occurrence in the graph that is what I think it should be, then  
> bring a related field into an unused area of the parent's layout.  
> I'd expect to see the first related child record's data. Then a  
> simple 6 line portal over that. A serial field or some other  
> identifiable data from the related records would be my choice. Kind  
> of a take it from the top approach.
>
> I've certainly fought this one before.
>
> Geoff

[Flora, Charlene]

I have a child db with fields sport, participation status, and department related to main db with fields: sport, participation status, and department. The child db has C for participation status. The portal is in the child db and sees only records for the sport, dept and "C" only. The relationship window is:  child db on left and main db on right.



Charlene M. Flora
Administrative Assistant
Division of Athletic Training/Sports Medicine
Intercollegiate Athletics for Men and Women
The University of Texas at Austin
P. O. Box 7399
Austin, TX 78713-7399
512/589-0480

This message is for the designated recipient(s) only. It may contain privileged, proprietary, or otherwise confidential information. If you have received this message in error, please notify the sender immediately and delete the original. If this message contains Protected Health Information as defined by the HIPAA Privacy Rule, any dissemination, distribution or reproduction by a designated recipient to an entity not authorized by HIPAA Privacy Rule to have access to the information is strictly prohibited.



-----Original Message-----
From: FileMaker Pro Discussions on behalf of Peter Kilcoyne
Sent: Thu 10/8/2009 1:03 PM
To: [hidden email]
Subject: Re: Relationship Issue
 
Geoff, Steve, and John:

In my original database relationship Table_Jobspecs (MarComProjects)  
is related to Parts via ProjNum=ProjNum_job AND  
Constant=Constant_Job. I duplicated the same relationship and swapped  
Constant and Constant_job with Mail and Mail_job naively thinking  
this would work and changed the name (since you can't have two named  
the same) to Mail. This maybe where I went wrong.

Comments?

Also if I un-index the fields Mail and Mail_job nothing shows up.

Peter
On Oct 8, 2009, at 8:37 AM, Geoff Graham wrote:

> On Oct 7, 2009, at 4:51 PM, Steve Cassidy wrote:
>> ...
>
>> But then I've now had a further glass of wine. I could be wrong.
> ...
>
> One more glass Steve and you may attain true clarity.
>
> Peter,
>
> The line from the starting table occurrence (the layout) to the  
> destination table occurrence (portal content) is not what your  
> portal wants it to be. Now if you're sure the portal is set right,  
> that leaves your relationship graph. It's one of the two right? You  
> ruled out calculations evaluating from the wrong context.
>
> I'd start troubleshooting by placing another (temporary) table  
> occurrence in the graph that is what I think it should be, then  
> bring a related field into an unused area of the parent's layout.  
> I'd expect to see the first related child record's data. Then a  
> simple 6 line portal over that. A serial field or some other  
> identifiable data from the related records would be my choice. Kind  
> of a take it from the top approach.
>
> I've certainly fought this one before.
>
> Geoff

[Peter Kilcoyne]

Charlene:
Do you have a relationship defined in the main db?

Peter
On Oct 8, 2009, at 3:59 PM, Flora, Charlene wrote:

> I have a child db with fields sport, participation status, and  
> department related to main db with fields: sport, participation  
> status, and department. The child db has C for participation  
> status. The portal is in the child db and sees only records for the  
> sport, dept and "C" only. The relationship window is:  child db on  
> left and main db on right.
>
>
>
> Charlene M. Flora
> Administrative Assistant
> Division of Athletic Training/Sports Medicine
> Intercollegiate Athletics for Men and Women
> The University of Texas at Austin
> P. O. Box 7399
> Austin, TX 78713-7399
> 512/589-0480
>
> This message is for the designated recipient(s) only. It may  
> contain privileged, proprietary, or otherwise confidential  
> information. If you have received this message in error, please  
> notify the sender immediately and delete the original. If this  
> message contains Protected Health Information as defined by the  
> HIPAA Privacy Rule, any dissemination, distribution or reproduction  
> by a designated recipient to an entity not authorized by HIPAA  
> Privacy Rule to have access to the information is strictly prohibited.
>
>
>
> -----Original Message-----
> From: FileMaker Pro Discussions on behalf of Peter Kilcoyne
> Sent: Thu 10/8/2009 1:03 PM
> To: [hidden email]
> Subject: Re: Relationship Issue
>
> Geoff, Steve, and John:
>
> In my original database relationship Table_Jobspecs (MarComProjects)
> is related to Parts via ProjNum=ProjNum_job AND
> Constant=Constant_Job. I duplicated the same relationship and swapped
> Constant and Constant_job with Mail and Mail_job naively thinking
> this would work and changed the name (since you can't have two named
> the same) to Mail. This maybe where I went wrong.
>
> Comments?
>
> Also if I un-index the fields Mail and Mail_job nothing shows up.
>
> Peter
> On Oct 8, 2009, at 8:37 AM, Geoff Graham wrote:
>
>> On Oct 7, 2009, at 4:51 PM, Steve Cassidy wrote:
>>> ...
>>
>>> But then I've now had a further glass of wine. I could be wrong.
>> ...
>>
>> One more glass Steve and you may attain true clarity.
>>
>> Peter,
>>
>> The line from the starting table occurrence (the layout) to the
>> destination table occurrence (portal content) is not what your
>> portal wants it to be. Now if you're sure the portal is set right,
>> that leaves your relationship graph. It's one of the two right? You
>> ruled out calculations evaluating from the wrong context.
>>
>> I'd start troubleshooting by placing another (temporary) table
>> occurrence in the graph that is what I think it should be, then
>> bring a related field into an unused area of the parent's layout.
>> I'd expect to see the first related child record's data. Then a
>> simple 6 line portal over that. A serial field or some other
>> identifiable data from the related records would be my choice. Kind
>> of a take it from the top approach.
>>
>> I've certainly fought this one before.
>>
>> Geoff

[Peter Kilcoyne]

Geoff, Steve, Flora, and John and anyone else that even considered my  
conundrum:

First of all thanks a bunch! Second Steve you were right, I did not  
have all the fields from the same TO, but it took Geoff to point that  
out to me. He very generously review my tables and layout. I thought  
only the match field was required to be from the same TO as the  
Portal. Now I have the relationship correct and the portal fields  
correct and it works.

Thanks again to all,
Peter
On Oct 9, 2009, at 2:20 PM, Geoff Graham wrote:

> Took me a while to get to it...
>
> If I've got the right layout, your problem was that all the fields  
> in the Mail portal were based on the Parts TO, I'm sure from  
> copying and duplicating. I changed them all to pull from Mail  
> instead of Parts and it appears to work. I had to make up values  
> for the records to test with; I'll have to assume that your keys  
> are in order.
>
> but having the fields drawing from a different TO than the portal  
> would have caused the symptoms you described.
>
> hope I've helped,
>
> Geoff
>
> <PartsAndMail.zip>
>
>
> On Oct 9, 2009, at 10:43 AM, Peter Kilcoyne wrote:
>
>> sorry forgot.
>>
>> PK
>> inkspot
>> On Oct 9, 2009, at 10:45 AM, Geoff Graham wrote:
>>
>>> Peter,
>>>
>>> It's wanting a user/password...
>>>
>>> Geoff
>>>
>>>
>>> On Oct 9, 2009, at 9:54 AM, Peter Kilcoyne wrote:
>>>
>>>> Geoff:
>>>>
>>>> I appreciate your offer. I have attached clones with out records  
>>>> for the two databases in question. There are other databases  
>>>> that will be missing but they shouldn't effect this portal  
>>>> issue. I did try duplicating a portal that works perfectly and  
>>>> added the Mail =mail_job fields without success. That is what  
>>>> troubles me, one portal relationship that works correctly;  
>>>> duplicating it exactly and the dupe not working.
>>>>
>>>> Anyway I appreciate your comments.
>>>>
>>>> Peter
>>>>
>>>> <Parts Clone.fp7><MarComProjects Clone.fp7>
>>>> On Oct 9, 2009, at 9:23 AM, Geoff Graham wrote:
>>>>
>>>>> Well, I'm not really seeing it. I'd love to take a look though  
>>>>> if you want to send me something.
>>>>>
>>>>> Your key field; Mail, being on the left hand side of your  
>>>>> relationship looking from your parent layout, wouldn't  
>>>>> necessarily have to be indexed; but the foreign key; Mail_job,  
>>>>> would definitely have to be for a relationship to work that  
>>>>> uses it.
>>>>>
>>>>> Geoff
>>>>>
>>>>> On Oct 8, 2009, at 2:03 PM, Peter Kilcoyne wrote:
>>>>>
>>>>>> Geoff, Steve, and John:
>>>>>>
>>>>>> In my original database relationship Table_Jobspecs  
>>>>>> (MarComProjects) is related to Parts via ProjNum=ProjNum_job  
>>>>>> AND Constant=Constant_Job. I duplicated the same relationship  
>>>>>> and swapped Constant and Constant_job with Mail and Mail_job  
>>>>>> naively thinking this would work and changed the name (since  
>>>>>> you can't have two named the same) to Mail. This maybe where I  
>>>>>> went wrong.
>>>>>>
>>>>>> Comments?
>>>>>>
>>>>>> Also if I un-index the fields Mail and Mail_job nothing shows up.
>>>>>>
>>>>>> Peter
>>>>>> On Oct 8, 2009, at 8:37 AM, Geoff Graham wrote:
>>>>>>
>>>>>>> On Oct 7, 2009, at 4:51 PM, Steve Cassidy wrote:
>>>>>>>> ...
>>>>>>>
>>>>>>>> But then I've now had a further glass of wine. I could be  
>>>>>>>> wrong.
>>>>>>> ...
>>>>>>>
>>>>>>> One more glass Steve and you may attain true clarity.
>>>>>>>
>>>>>>> Peter,
>>>>>>>
>>>>>>> The line from the starting table occurrence (the layout) to  
>>>>>>> the destination table occurrence (portal content) is not what  
>>>>>>> your portal wants it to be. Now if you're sure the portal is  
>>>>>>> set right, that leaves your relationship graph. It's one of  
>>>>>>> the two right? You ruled out calculations evaluating from the  
>>>>>>> wrong context.
>>>>>>>
>>>>>>> I'd start troubleshooting by placing another (temporary)  
>>>>>>> table occurrence in the graph that is what I think it should  
>>>>>>> be, then bring a related field into an unused area of the  
>>>>>>> parent's layout. I'd expect to see the first related child  
>>>>>>> record's data. Then a simple 6 line portal over that. A  
>>>>>>> serial field or some other identifiable data from the related  
>>>>>>> records would be my choice. Kind of a take it from the top  
>>>>>>> approach.
>>>>>>>
>>>>>>> I've certainly fought this one before.
>>>>>>>
>>>>>>> Geoff
>>>>>
>>>>
>>>
>

[John Weinshel]

Which suggests that drinking while developing may not be such a bad idea.


John Weinshel
Datagrace
Vashon Island, WA
[phone]
Member, FileMaker Business Alliance
Certified For FileMaker 10


-----Original Message-----
From: FileMaker Pro Discussions [mailto:[hidden email]] On
Behalf Of Peter Kilcoyne
Sent: Friday, October 09, 2009 12:06 PM
To: [hidden email]
Subject: Re: Relationship Issue

Geoff, Steve, Flora, and John and anyone else that even considered my  
conundrum:

First of all thanks a bunch! Second Steve you were right, I did not  
have all the fields from the same TO, but it took Geoff to point that  
out to me. He very generously review my tables and layout. I thought  
only the match field was required to be from the same TO as the  
Portal. Now I have the relationship correct and the portal fields  
correct and it works.

Thanks again to all,
Peter
On Oct 9, 2009, at 2:20 PM, Geoff Graham wrote:

> Took me a while to get to it...
>
> If I've got the right layout, your problem was that all the fields  
> in the Mail portal were based on the Parts TO, I'm sure from  
> copying and duplicating. I changed them all to pull from Mail  
> instead of Parts and it appears to work. I had to make up values  
> for the records to test with; I'll have to assume that your keys  
> are in order.
>
> but having the fields drawing from a different TO than the portal  
> would have caused the symptoms you described.
>
> hope I've helped,
>
> Geoff
>
> <PartsAndMail.zip>
>
>
> On Oct 9, 2009, at 10:43 AM, Peter Kilcoyne wrote:
>
>> sorry forgot.
>>
>> PK
>> inkspot
>> On Oct 9, 2009, at 10:45 AM, Geoff Graham wrote:
>>
>>> Peter,
>>>
>>> It's wanting a user/password...
>>>
>>> Geoff
>>>
>>>
>>> On Oct 9, 2009, at 9:54 AM, Peter Kilcoyne wrote:
>>>
>>>> Geoff:
>>>>
>>>> I appreciate your offer. I have attached clones with out records  
>>>> for the two databases in question. There are other databases  
>>>> that will be missing but they shouldn't effect this portal  
>>>> issue. I did try duplicating a portal that works perfectly and  
>>>> added the Mail =mail_job fields without success. That is what  
>>>> troubles me, one portal relationship that works correctly;  
>>>> duplicating it exactly and the dupe not working.
>>>>
>>>> Anyway I appreciate your comments.
>>>>
>>>> Peter
>>>>
>>>> <Parts Clone.fp7><MarComProjects Clone.fp7>
>>>> On Oct 9, 2009, at 9:23 AM, Geoff Graham wrote:
>>>>
>>>>> Well, I'm not really seeing it. I'd love to take a look though  
>>>>> if you want to send me something.
>>>>>
>>>>> Your key field; Mail, being on the left hand side of your  
>>>>> relationship looking from your parent layout, wouldn't  
>>>>> necessarily have to be indexed; but the foreign key; Mail_job,  
>>>>> would definitely have to be for a relationship to work that  
>>>>> uses it.
>>>>>
>>>>> Geoff
>>>>>
>>>>> On Oct 8, 2009, at 2:03 PM, Peter Kilcoyne wrote:
>>>>>
>>>>>> Geoff, Steve, and John:
>>>>>>
>>>>>> In my original database relationship Table_Jobspecs  
>>>>>> (MarComProjects) is related to Parts via ProjNum=ProjNum_job  
>>>>>> AND Constant=Constant_Job. I duplicated the same relationship  
>>>>>> and swapped Constant and Constant_job with Mail and Mail_job  
>>>>>> naively thinking this would work and changed the name (since  
>>>>>> you can't have two named the same) to Mail. This maybe where I  
>>>>>> went wrong.
>>>>>>
>>>>>> Comments?
>>>>>>
>>>>>> Also if I un-index the fields Mail and Mail_job nothing shows up.
>>>>>>
>>>>>> Peter
>>>>>> On Oct 8, 2009, at 8:37 AM, Geoff Graham wrote:
>>>>>>
>>>>>>> On Oct 7, 2009, at 4:51 PM, Steve Cassidy wrote:
>>>>>>>> ...
>>>>>>>
>>>>>>>> But then I've now had a further glass of wine. I could be  
>>>>>>>> wrong.
>>>>>>> ...
>>>>>>>
>>>>>>> One more glass Steve and you may attain true clarity.
>>>>>>>
>>>>>>> Peter,
>>>>>>>
>>>>>>> The line from the starting table occurrence (the layout) to  
>>>>>>> the destination table occurrence (portal content) is not what  
>>>>>>> your portal wants it to be. Now if you're sure the portal is  
>>>>>>> set right, that leaves your relationship graph. It's one of  
>>>>>>> the two right? You ruled out calculations evaluating from the  
>>>>>>> wrong context.
>>>>>>>
>>>>>>> I'd start troubleshooting by placing another (temporary)  
>>>>>>> table occurrence in the graph that is what I think it should  
>>>>>>> be, then bring a related field into an unused area of the  
>>>>>>> parent's layout. I'd expect to see the first related child  
>>>>>>> record's data. Then a simple 6 line portal over that. A  
>>>>>>> serial field or some other identifiable data from the related  
>>>>>>> records would be my choice. Kind of a take it from the top  
>>>>>>> approach.
>>>>>>>
>>>>>>> I've certainly fought this one before.
>>>>>>>
>>>>>>> Geoff
>>>>>
>>>>
>>>
>

[Jens Selvig-2]

Of course, at this point this drinking wine theory is only anecdotal.  
Perhaps some clinical trials would be in order, but I'd suggest the  
experiment be limited to Friday afternoons. ;)

Jens

Mostly frozen in Montana,



On Oct 9, 2009, at 1:52 PM, John Weinshel wrote:

> Which suggests that drinking while developing may not be such a bad  
> idea.
>
>
> John Weinshel
> Datagrace
> Vashon Island, WA
> [phone]
> Member, FileMaker Business Alliance
> Certified For FileMaker 10
>
>
> -----Original Message-----
> From: FileMaker Pro Discussions [mailto:FMPRO-
> [hidden email]] On
> Behalf Of Peter Kilcoyne
> Sent: Friday, October 09, 2009 12:06 PM
> To: [hidden email]
> Subject: Re: Relationship Issue
>
> Geoff, Steve, Flora, and John and anyone else that even considered my
> conundrum:
>
> First of all thanks a bunch! Second Steve you were right, I did not
> have all the fields from the same TO, but it took Geoff to point that
> out to me. He very generously review my tables and layout. I thought
> only the match field was required to be from the same TO as the
> Portal. Now I have the relationship correct and the portal fields
> correct and it works.
>
> Thanks again to all,
> Peter
> On Oct 9, 2009, at 2:20 PM, Geoff Graham wrote:
>
>> Took me a while to get to it...
>>
>> If I've got the right layout, your problem was that all the fields
>> in the Mail portal were based on the Parts TO, I'm sure from
>> copying and duplicating. I changed them all to pull from Mail
>> instead of Parts and it appears to work. I had to make up values
>> for the records to test with; I'll have to assume that your keys
>> are in order.
>>
>> but having the fields drawing from a different TO than the portal
>> would have caused the symptoms you described.
>>
>> hope I've helped,
>>
>> Geoff
>>
>> <PartsAndMail.zip>
>>
>>
>> On Oct 9, 2009, at 10:43 AM, Peter Kilcoyne wrote:
>>
>>> sorry forgot.
>>>
>>> PK
>>> inkspot
>>> On Oct 9, 2009, at 10:45 AM, Geoff Graham wrote:
>>>
>>>> Peter,
>>>>
>>>> It's wanting a user/password...
>>>>
>>>> Geoff
>>>>
>>>>
>>>> On Oct 9, 2009, at 9:54 AM, Peter Kilcoyne wrote:
>>>>
>>>>> Geoff:
>>>>>
>>>>> I appreciate your offer. I have attached clones with out records
>>>>> for the two databases in question. There are other databases
>>>>> that will be missing but they shouldn't effect this portal
>>>>> issue. I did try duplicating a portal that works perfectly and
>>>>> added the Mail =mail_job fields without success. That is what
>>>>> troubles me, one portal relationship that works correctly;
>>>>> duplicating it exactly and the dupe not working.
>>>>>
>>>>> Anyway I appreciate your comments.
>>>>>
>>>>> Peter
>>>>>
>>>>> <Parts Clone.fp7><MarComProjects Clone.fp7>
>>>>> On Oct 9, 2009, at 9:23 AM, Geoff Graham wrote:
>>>>>
>>>>>> Well, I'm not really seeing it. I'd love to take a look though
>>>>>> if you want to send me something.
>>>>>>
>>>>>> Your key field; Mail, being on the left hand side of your
>>>>>> relationship looking from your parent layout, wouldn't
>>>>>> necessarily have to be indexed; but the foreign key; Mail_job,
>>>>>> would definitely have to be for a relationship to work that
>>>>>> uses it.
>>>>>>
>>>>>> Geoff
>>>>>>
>>>>>> On Oct 8, 2009, at 2:03 PM, Peter Kilcoyne wrote:
>>>>>>
>>>>>>> Geoff, Steve, and John:
>>>>>>>
>>>>>>> In my original database relationship Table_Jobspecs
>>>>>>> (MarComProjects) is related to Parts via ProjNum=ProjNum_job
>>>>>>> AND Constant=Constant_Job. I duplicated the same relationship
>>>>>>> and swapped Constant and Constant_job with Mail and Mail_job
>>>>>>> naively thinking this would work and changed the name (since
>>>>>>> you can't have two named the same) to Mail. This maybe where I
>>>>>>> went wrong.
>>>>>>>
>>>>>>> Comments?
>>>>>>>
>>>>>>> Also if I un-index the fields Mail and Mail_job nothing shows  
>>>>>>> up.
>>>>>>>
>>>>>>> Peter
>>>>>>> On Oct 8, 2009, at 8:37 AM, Geoff Graham wrote:
>>>>>>>
>>>>>>>> On Oct 7, 2009, at 4:51 PM, Steve Cassidy wrote:
>>>>>>>>> ...
>>>>>>>>
>>>>>>>>> But then I've now had a further glass of wine. I could be
>>>>>>>>> wrong.
>>>>>>>> ...
>>>>>>>>
>>>>>>>> One more glass Steve and you may attain true clarity.
>>>>>>>>
>>>>>>>> Peter,
>>>>>>>>
>>>>>>>> The line from the starting table occurrence (the layout) to
>>>>>>>> the destination table occurrence (portal content) is not what
>>>>>>>> your portal wants it to be. Now if you're sure the portal is
>>>>>>>> set right, that leaves your relationship graph. It's one of
>>>>>>>> the two right? You ruled out calculations evaluating from the
>>>>>>>> wrong context.
>>>>>>>>
>>>>>>>> I'd start troubleshooting by placing another (temporary)
>>>>>>>> table occurrence in the graph that is what I think it should
>>>>>>>> be, then bring a related field into an unused area of the
>>>>>>>> parent's layout. I'd expect to see the first related child
>>>>>>>> record's data. Then a simple 6 line portal over that. A
>>>>>>>> serial field or some other identifiable data from the related
>>>>>>>> records would be my choice. Kind of a take it from the top
>>>>>>>> approach.
>>>>>>>>
>>>>>>>> I've certainly fought this one before.
>>>>>>>>
>>>>>>>> Geoff
>>>>>>
>>>>>
>>>>
>>

Jens Selvig
...Lost in Montana...

[Steve Cassidy]

On Oct 9, 2009, at 10:06 PM, Jens Selvig wrote:

> Of course, at this point this drinking wine theory is only  
> anecdotal. Perhaps some clinical trials would be in order, but I'd  
> suggest the experiment be limited to Friday afternoons. ;)

Friday afternoons?

Where I live, and depending on your profession, it can be considered  
reasonable to start around 9am Monday morning.

Steve