Using a "New Window" as a Self Join Portal

[George from Pittsburgh]

I have created a portal in a "new widow" in order to select a related record in an original window. The portal list names in the table. By clicking on a name, I can get to that persons record in a layout of my choice. Every thing works fine but the action in the "new window" takes me to a layout and related record in the "new window" instead of the original window which is my objective.

How do I modify the script in the "new window" in such a way as to get to the related record in the original window?

I hope that's not too confusing.

[Fenton]

I just posted an example file which does this. The "choice" window is a temporary window, ie., it's closed after use. Here's the link to the example file:

http://www.fmforums.com/threads/download.php?Number=122273

[George from Pittsburgh]

"Fenton",

Your solution is exactly what I was looking for. Thank you.

I have been trying to adapt it to my solution and am experiencing a bit of a problem where the alpha keys reveal the related records.

Would it be too much of a presumption for me to ask you to look at it if I fail to find the problem?

[Fenton]

Sure, I could. Why don't you post your file here. You only need a little data in it; I'll be able to see what's wrong hopefully without needing tons of data. I'm kind of supposed to be doing something else, but I may get bored with it :-/

Did you look carefully at the script that creates (or not) the New Window? Also, it's pretty important that the buttons have the correct option, usually "Halt Script." Else you get stuck in the Loop/pause routine and can't get out.

[George from Pittsburgh]

Post deleted by George from Pittsburgh

[Fenton]

I'm afraid I've got to run. But what I can tell you right away that you are targetting an Unstored calculation field with a relationship. This will never work.

Last_c MUST be a stored field. It will either be built from the Last Name field in the file it's in.

Or the Last_c field should be created in the student file, from the Last Name field, where it would be a stored calculation, and the relationship will target that.

But it should not be a calculation using the related Last name field in the student file, which it is now.

It's difficult for me to quickly tell you which it should be. I am not even sure the Last Name field in its current file is the student name. There is no label saying so; I can't tell what mechanism is filling it; nor do I know exactly what your files are from their cryptic names.

I can figure it out, but it'll have to be later; food is running out and laundry is piling up :-).

It would help if you would describe in plain English what it is you expect the choice to do:

1. Navigate to a record in the current file (seems like)

2. Set a field in the current file to a student from the student file

These are 2 very different operations.

[Fenton]

OK, I redid it, so that it's finding on the Last name field in SNP. I also fixed up its "sister" portal on the Contact Data layout, so you can do new searches right from there (don't worry, it's non-printing).

I'm only attaching the SNP file; 'cause that's the only one I changed, and the other one is really too big to post on the forum. You should probably delete your original file; it's big and it's broken.

You're aware I guess that your SNP file has extra spaces in front? Kind of too late to change now (unless you have Developer).

SNP_03-04.zip

[George from Pittsburgh]

It works just fine. I removed the attachment as you had suggested.

I removed the "New" button as I didn't need it. I noticed that "CountMatches_c" was not conneected to a table or field. Is this a problem or should I just ignore it?

I am trying to decide between the two portals and have concluded that your portal in the new window is much more elegant.

Thanks again for your help.

[George from Pittsburgh]

Fenton,

Upon further examination, I find that it is not working. I am posting a zipped file for your review.

It does not select all records by last name. Since I use a related field, "::FullName from the "Chi" file, "Last Name has no value in "SNP". I wrote a script to set the "last name" field in "SNP", the "last name" field in "CHI" (Script-Set Last Name).

At this point, each record in "SNP" has a value for "Last Name". The problem now is that there can be more than 1 record with the same "Last Name" (multiple visits to the health office). I thought about running a script to omit duplicates and constrain the found set, but can't seem to come up with a scheme to do it and I'm not sure the portal would then choose (display) one record for each person.

I'm sorry to be such a bother.

1094666434-NewHealth9:8Test.zip

[George from Pittsburgh]

I think I got it!!

Please check attached.

I developed a script (Set Last Name) which sets the value of last name in SNP to the value in CHI. Then a subscript (Check For Duplicates) finds duplicate last names and clears the Last Name value in all but the last of each duplicate set. At that point, the relationship only yields one record for each set of visits per client and returns the last visit.

Thank you so much for all of your help.

FinalHealth.zip

[Fenton]

Say what? That's an interesting method to find duplicates, with Looping Find. It had several extra steps and wasn't optimized, so I redid it.

But it's kind of a crazy way to do what you want, deleting last names. You have a StudentID; you shouldn't be using names; they're for sissies :-)

I don't really know what you're trying to do with this; what data do you want, and where do you want to see it from?

However:

If you sort a relationship descending by something like a serial ID or Date/Time, then it will return the last record matching.

or

The function: Last (relationship::field) will return the value of field in the last record (in creation order) of an unsorted relationship.

SNP_03-04.zip

[QuinTech]

I have created a portal in a "new widow"

Were you in "Being John Malkovich?"

Sorry, couldn't resist.

Jerry (from Pittsburgh)