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
