Jump to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Go To Related Record Not Working As Expected

Featured Replies

I've got a simple relationship. Customer->Order via customerID as a foreign key in Order table. Typical operation, I want to jump to the record that I click on from the portal row.

When I put a simple button with a script step Go To Related Record on the portal row it works properly.

When I create a script with GTRR and some other steps in there attached to that same button, it always brings me to the wrong record. I've even tried grabbing the OrderID from the portal row and performing a search, but it always grabs the wrong Order ID. I've experienced this before, but I can't remember what I did to fix it. 

 

Any ideas?

When I create a script with GTRR and some other steps in there attached to that same button, it always brings me to the wrong record.

Your question would be a lot easier to answer if you had spelled out those "other steps in there". As it is, one can only guess that one of them takes you out of the clicked portal row. Or perhaps you're going to the wrong TO of the child table.

 

I've even tried grabbing the OrderID from the portal row and performing a search, but it always grabs the wrong Order ID.

Same thing.

  • Author

The scripts are all correct. I forgot to mention, my script does "commit records" before GTRR.

In order to make it work, I had to:

  1. grab the ID(Set Variable) of the portal row record first,
  2. commit records, <-calling this before a GTRR in portal
  3. new window,
  4. go to layout
  5. perform find $orderID
  6. Exit Script

I suppose I could also do:

  1. Set Variable Get(ActivePortalRowNumer) $portalRow
  2. Commit Records
  3. Go To Object "My Portal"
  4. Go To Portal Row $portalRow
  5. GTRR...
  6. Exit Script

Any thoughts on performance of either?

Yes, well the Commit[] is a problem. Once you commit, that portal row now longer has focus so the rest of the script doesn't "know" that's the row you want.

You could do the find. That's my general preference over GTRR. But you could simply take the Commit[] out. If you've edited the record (parent or child) and GTRR with a New Window[] that might record locking issues.

 

  • Author

Yea. It threw me for a loop and I was working late last night. I need the commit because I was getting some locking issues(301) when trying to write back to the Customer Table from the context of the Order table. 

suppose I could also do:

  1. Set Variable Get(ActivePortalRowNumer) $portalRow
  2. Commit Records
  3. Go To Object "My Portal"
  4. Go To Portal Row $portalRow

Well, theoretically after the Commit[], in a sorted relationship/portal the portal rows could be in a different order, due to whatever changes you just saved, so that now the same rowNumber would be a different record … 

I suppose I could also do:

  1. Set Variable Get(ActivePortalRowNumer) $portalRow
  2. Commit Records
  3. Go To Object "My Portal"
  4. Go To Portal Row $portalRow
  5. GTRR...
  6. Exit Script

If you have uncommitted records in the current window, you could use GTRR with the 'Show in new window' option checked.

Create an account or sign in to comment

Important Information

By using this site, you agree to our Terms of Use.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.