• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 421
  • Last Modified:

FM - Best Way to Go to RR in External DB and Back Again

What would be the best way to go to a RR in an external db's layout and then return easily again given the following.  In the first db, Sales Leads, you have a portal at the bottom that shows all Vacancies a customer might be interested in.  This has a GTRR that brings you to the Vacancy db and layout.  However, a Lead is not related in any way to a particular vacancy, so how do you get back?  

I could set up a global in Vacancies and set it to the RecID of the Lead record that I am leaving and then have a Return button in Vacancies that takes me back using that global.  Any better way?  Maybe use the Hide Window and then Restore Window command, but not sure that would be reliable.

P.S. - I'm again having a problem.  GTRR works great by itself as one step when I set the appropriate portal field as a button.  However, if I try to put the GTRR in a script step (in this case so I can have an extra script step to capture the RecID in a global) it does NOT work.  I've been through this before and people don't believe me so attached are the screen prints.  Maybe a script works only in the local db, so cannot go to a related record in another db?  But then why does the external tables layouts show and are not grayed out or something?
  • 2
2 Solutions
If the Leads aren't related, how about opening the vacancies in a separate window.  This way you will have both and the user can switch back and forth as needed.
Will LovingPresidentCommented:
I think this might have to do with what has the "focus". When you click on a portal record that has just the Go to Related Record (GTRR) script step, it goes directly to that record. However, when you change it to a script that includes the capturing of the current Record ID to a global, it shifts the "focus" off of the related Vacancy portal record and onto the Sales Lead record. Then when you run the GTRR step, you are no longer focused on the portal record and so the step is invalid.

The way to test this is to use the script debugger, turn on stop on Error, and see if what error code is thrown when you hit the GTRR step in the script.

So, to make your existing setup work, you need to either have already captured the Record ID before you run the GTRR, or, you need to: capture the portal row being clicked on to a script variable e.g. $PortalRow, set the global field, use Go To Portal Row [ $PortalRow ] to get back to the portal record and then use GTRR to jump to the Vacancy record. That should make it work.

However, since there are separate files, I don't think you really need to do that. You can just hide the Sales Leads Window and display the Vacancies window. When you hit a button in vacancies to return to the Sales Leads window and Close or Hide Vacancies. If you want more control, you can capture the name of the original Sales window to a Global variable and then give the Vacancies window a specific name. You can then close the Vacancies window by name and Select the original window which should still be on the same record.
rvfowler2Author Commented:
Thanks N2A for the separate window idea; I can still close it when finished, and thanks to Will for soving something that's been puzzling to me for awhle - why GTRR sometimes works within a script and sometimes not.  Probably doesn't work within a script when called from a portal, but will test and post this afterward.
Will LovingPresidentCommented:
GTRR  should work just fine from within a portal but only as long as the focus stays in the portal. If you move away from the related portal record, there is no longer a "RR" to "GT".
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now