Is there any way to specify a table by calculation in Goto Related?

[Ron Cates]

Is there any way to specify a table by calculation in Goto Related Record?

Pretty sure the answer is no, just looking for confirmation i guess :)

[LaRetta]

Hi Ron,

Unfortunately, no way using the GTRR script step. There are alternatives: a find or If/Else script construct with each GTRR within.

[Ron Cates]

Thanks LaRetta. I'm trying to write a modular save and restore found set script that is part of a scripted find button that emulates Filemakers Find button. ( So I can hide the status bar ). I have this already in place and I pass the table and original layout by script parameter then GTRR using the unrelated TO which saves the found set, then back to the original layout to continue the find script. If the find returns 0 results the original found set can be restored by going to the unrelated TO and going back to the original table and layout using GTRR. Right now i do use a series of if/elseifs to GTRR in the appropriate TO but was hoping to find a way to make it purely modular so I wouldn't have to adjust the script for every layout bases on a new table that I want to add this button to.

For every table I have a developer TO such as "@ Table" ( as recomended on the filemakerstandards.org project ) so I had hoped to use the table name passed in a parameter to GTRR using "@ $table". I think to use a find to reproduce the found set in the unrelated TO could cause problems if it's a large found set, so I think I'm probably stuck adding an elsif for each new table i need. Unless anyone can think of a better way?

Is there a way to reproduce a found set in another TO that would be as instantanious and seemless as GTRR?

For my current solution it's not much of a problem to set up the elseifs for the appropriate tables. But since I have been given the opartunity to completely redevelop a monster system I've been working on for 3 years, I'm trying to develop a starter file ( or two as I'm converting to data seperation ) that I can use for future projects as well.

Maybe I should submit a new feature request to provide for using a table by calculation in GTRR. I have run across a few other functions that could benefit from allowing for criteria by calculation. OK, I can't think of any others right this moment, but I know I have seen them.

Thanks for any insight :flowers:

[LaRetta]

I think to use a find to reproduce the found set in the unrelated TO could cause problems if it's a large found set,

It seems that some people think a GTRR is faster than a find but that is not the case (at least not since vs. 8, IIRC) - they are the same animal. And GTRR requires adding complexity to the graph. With finds, you can use Set Field By Name [ ], Get Field() and many other tools to accomplish the task dynamically, all without graph clutter. Finds are clean, dependable workhorses.

[dansmith65]

I think the part that can take longer is constructing the find request. The only method I can think of to save/restore a found set without using a separate table occurrence is to loop through the records, gathering primary key's in a value list. I would imagine this loop wouldn't be as instantaneous as a GTRR for a large found set.

Regarding large found set's: I used a technique like you were mentioning Ron, but I put in some tests so that the found set wasn't saved if all records were found. Another method is to not save the found set if x% of the total records are found. I think what's appropriate for a percentage may vary depending on the system though (and will likely vary per table).

Here is blog post on this topic: http://www.dbservices.com/articles/saving-and-restoring-filemaker-found-sets

An alternative method I have used is to perform find's in a new window. To restore the previous found set, you can close the window. If the find was successful, you can close the old window, then rename/move the new one to where the old one was.

[Ron Cates]

@ Laretta - The beauty of this technique is that it doesn't require additional relationships or TOs, other than if you don't have a set of TOs already in place that can be used for this purpose, such as my deaveloper TOs which are already there anyway.

@ dansmith65 - That link very accurately explains why I chose to use this method,

So, back to my original idea. I guess until FilleMaker adds the ability to specify a table by calculation in GTRR i'm stuck with a series of elseifs to accomplish my save / restore found set. It's really not that much work, especially when you consider that any other method to reproduce the found set in another TO using a find, and being able to restore the found set as well as land the user on the right record would require a lot more work and run the risk of a performance hit to boot.

As for using a hidden window, On windows, openning a new window causes the main window to reduce. I can easily restore it when the find script is done but it makes for a very ugly user experience. For that reason i avoid using any off screen / hidden window techniques.

The only other problem it leaves me with is restoring the current tab and portal position to truely make it seemless. Although a good navigation solution such as Back Magic should solve that issue. I am still looking for the right navigation solution. Back Magic is pretty geed but I don't believe it restores portal positions. And yes, I know there's really no way to restore the exact portal position but there are methods that come very close. So if you know of a good navigation system please let me know. Otherwise I'm just going to build one that meets my needs.

Once again, thanks for the input :smile:

[dansmith65]

I understand you not wanting to mess around with creating new windows on Windows OS (ironic isn't it?), especially if you run the main window maximized. I'm not sure that you understood what I was suggesting by performing finds in new windows, so I'll explain it a little more thouroughly...

1. When user clicks find, open new window, maximize (in your case), go to find layout, pause the script
   
2. User enters their find request, then either Performs the find, or cancels it.
   
3. If the find was successfull: close your main window, rename the find window to match the main window
   
4. To cancel the find/restore previous find: close the find window
   

The only down-side I can see to this is the initial flashing when a new window is opened while the previous window is maximized.

[Ron Cates]

It is certainly a valid technique and one I hadn't thought of.

[comment]

The only down-side I can see to this is the initial flashing when a new window is opened while the previous window is maximized.

There are more possible downsides to consider, such as losing all found sets of the "old" window, or scripts installed to run OnTimer.

[Ron Cates]

I'm actually very happy with the technique i'm using and will probably stick with it :)