Moving Found Set To A New File

[Brian C]

I have 3 files in FM8.5 for this scenario:

1) GUI (File Refs, TOs, relationships, scripts)

2) Data (Tables, Data ,TOs to support calc fields)

3) Print (TOs, relationships, scripts)

I need to be able to move a found set from the gui file to the print file so that when a user goes to print a form or report, the found set will mirror what they were viewing in the gui. I need this to be IWP compatible if possible.

[mr_vodka]

Why not just import the found set into the print file?

[Genx]

... Why don't you display the info using an external layout?

[Brian C]

Mr Vodka:

I cannot use the import function since it is not a IWP compatible script step.

Genx:

Could you please explain a bit more of what you mean by your layout reference?

Scenerio:

The user will be accessing the information initially on a layout located in the GUI file.

User locates found set.

User goes to print a report or form letter.

I want to transfer the found set to a layout/TO in the Print file where all reports and forms reside.

My current idea is:

1) create a multi-key of all the record keys for the current found set

2) transfer multikey using [set variable] to the destination file

3) Store the multi-key in a global field

4) use a self relationship to locate the found set using the multikey

What limitations will I run into using this approach?

Will it work with IWP?

Is there a better easier way? (I hope there is) B)

[Genx]

Well to be honest i haven't played with this much but as far as i can tell in you're scenario, the print file has access to the data in your data file...

When using the Go To Related Records (GTRR) script step in your GUI, you have the option to display the data using external table's layouts -- i.e. layouts in referenced files (in this case your print file) that are based on the same table as the TO you are GTRR'ing to is... So as far as i can see if:

1) You establish your found set

2) You are on the found set layout and you GTRR to the same Table Occurance (TO) that your found set layout is based on

EDIT:

3) Configure GTRR to Show matching records, Matching all records in the found set options.

END EDIT

4) In the GTRR step above, you Show records using an external layout in your referenced print file where that external layout is based on the same table (not TO) that your found set is based in

You wouldn't have to replicate your found set in the print file.

Edited January 30, 2007 by Guest
Forgot to mention what ender describes below

[Brian C]

I know I read something a long time back on a post on this board that seemed to be much easier than what I was doing but I could not remember it to save my life. This sounds like what I was trying to remember. I tried doing some searches but seem to be unsuccessful in putting in the right info to get what I am looking for.

Time crunches and deadlines don't always make it easy for me to jog my memory or spend too much time exploring options.

Many many thanks Genx! I will give this approach a try.

[Ender]

Ya, use the GTRR with the Show matching records, Matching all records in the found set options.

If you need FM7 compatibility, you'll need to use the multi-key technique.

[Brian C]

Unfortunately this will not work. After attempting it I finally determined the problem by checking the help:

Go To Related Record

- Use External Table's Layouts

"Use external table's layouts opens the file containing the external table you specify and lets you choose a layout from that file in which to display the related record(s). This option is only available if the source relationship you selected references a table in another file."

As you can see this will work fine if the destination file is the one that contains the actual tables. If the destination file only contains TO's it will not work. There is no way to even specify what file you want to use prior to selecting the destination layout.

Background:

I use a gui file to store all business logic in order to ease upgrades and bug fixes.

I use a data file to keep the data tables separate from the logic.

I use a print file in order to allow clients limited design access so that they can add additional print layouts on an as needed basis.

It is looking more and more like I will have to use my multikey idea...

Does anyone have any ideas as to how to quickly generate a multikey on the found set faster than this?

My current idea is to:

Loop

set variable [$multikey] [substitute ( $multikey ; $multikey ; ($multikey & Data::ID & "¶") )]

Go To Record/Request/Page [Next;Exit after last]

End Loop

Edited January 31, 2007 by Guest
Added More Info

[LaRetta]

Hi Brian,

I haven't ran any speed test comparisons, but I *think* you can eliminate Substitute() which should be quicker and maybe the quotes around the pilcrow? Whether that improves the speed sufficiently; unknown but every bit helps. Without seeing your specific output, I'm unsure. But this produces straight multikey.

Set Variable [ $multikey ; $multikey & ID & ¶ ]

LaRetta :wink2:

Edited January 31, 2007 by Guest

[Ender]

For appending items to a list, this is a little more streamlined:

Loop

Set Variable [ $multikey; $multikey & ¶ & Data::ID ]

Go To Record/Request/Page [Next;Exit after last]

End Loop

Another method is to put the ID field on a separate layout and use Copy All Records to grab them all. Then Paste the list where you like.

I don't know which is faster.

[LaRetta]

Hi Mike, yep, -Queue- taught me that, by using the method I outlined, one doesn't end up with blank line at the beginning. I've used it ever since. I used to use your style. ^)

I miss JT.

Edited January 31, 2007 by Guest

[Brian C]

You got me before I had a chance to edit Thats what I get when I post before I test... hehe

I figured out the set variable issue after I started writing it. I started asking myself why I wasn't doing it the same way i would use set field in the same scenerio.

set variable [$multikey]

[$multikey & GetField(Get(LayoutTableName) & "::ID" ) & "¶"]

Using get(layouttablename) allows me to make the script more dynamic from one table to the next.

Now if FileMaker would only let me specify SetField in the same manner... Go To Object is not such an elegant workaround for set field indirection...

I will check on the "Copy All Records/Requests to see how that works out.

Thanks for the tips!

[Brian C]

I just reread and modified my statement to remove the quotes around the pilcrow. Is this new to v7 and 8?

My only other concerns with using this approach is what limitations I may run into when I start getting to millions of records... Something I will have to create a test scenerio for to see if it chokes on client or in IWP...

I know current fields can store 4 gb of text... I wonder if you can use the whole thing for a multikey or if it will truncate it after some point for relationship purposes...

[Ender]

Hey Brian,

Ya the quotes stopped being necessary in version 7.

Either technique will get pretty slow after 50,000 or 100,000 records, depending on network speed. You'll want to test it to see how it performs.

[Brian C]

This makes me wish FileMaker had an Append script step in order to speed things up...

Replacing the contents of a field or variable with the same contents + 1 new key seems a bit heavy handed by comparison...

Appending a new piece of data to the end of the field data or to a variable would be so much more efficient - provided that is now it was also handled in memory...

FM gets so many new feature requests from me hehe... here comes another one!

[Genx]

Sorry to get that original critical point wrong...

This is why i only ever do two file splits B)

[T-Square]

Well--

I only just saw this thread.

I have followed a different avenue. What I have done (in FM7) is build my UI report script so that it passes the relevant search criteria to the Print file script, which then replicates the search that was requested originally.

So, from the criteria screen (where my users select the day of week and date)

UIReportScript[it's something like]

Perform Script["external:Report Script"; Parameter: "day=" & _g_Day & "; date=" & _g_Date]

RPTReportScript:

Go To Layout["Search Layout"]

Enter Find Mode[]

Set Field["Dayname"; GetParamByName("day")]

Set Field["Date"; GetParamByName("date")]

Perform Find[]

{error capture and messaging if nec}

Go To Layout["MyReport"]

Enter Preview Mode[Pause]

Enter Browse Mode[]

Close Window

This works for me because I script the finds for the reports with a limited group of presets. However, I imagine you could use a search layout with a button that creates a set of field-value pairs that get passed along and parsed on the reportside. That could handle most search queries relatively efficiently.

Offhand, I can't recall how well-tested this approach is under IWP, but my intent was for it work there...

David

BTW: GetParamByName is a custom function...

[Brian C]

Thanks for the new approach David!

I like your idea for passing PRE-DEFINED search criteria to the print file for reports that have a known structure.

For the majority of the ad-hoc searching that happens I am thinking that maybe I will have to place find layouts within the print file itself to accomplish the kind of flexibility I am looking for. My users are always asking for 1 time searches for information that is requested by one vendor or another or if the state or federal gov changes something and they are trying to determine impact, etc.

[T-Square]

Brian--

I'm just reading through your last post again, and I'll note that as long as you're talking about a limited set of search *fields* (i.e., it's always the vendor name field), you can still use the approach I suggested. You'd just be sure to pass your users' values on to the print file, where the search can still be automated.

In other words, if you have a search form that allows searching on Vendor, Date, and Status (say), your search button would simply script a call to the Print file script, passing the variables: "vendor=" & gSrchVendor & "; date=" & gSrchDate & "; status=" & gSrchStatus

Your users get to do their searches, you look fabulous, and you get a big raise (at least you should)...

David

[Brian C]

I know that FMP remembers the last search criteria used in a find - It allows you to store it as a saved search in a script, but unfortunately that is where it ends...

If only there were a way to use that or GTRR.

This is one big drawback to the sep model I suppose until this issue is addressed by FMP - I pray by the next version release.

In many cases I am dealing with 10-30 fields on a layout for users to perform an ad-hoc search within. There is no telling which fields will be used at any given time in a given search or how many steps will be performed to narrow down that found set (using the extend and constrain after a new found set is determined)

Placing the search and browse/list layouts in the print file seems to be the only real alternative I have at this time if I am going to have the report layouts exist there.

Another solution I may consider, provided I have the time to work it out would be to:

1) Name all the fields with object names on the search layout.

2) Loop and Tab thru and store the object names of the fields and their contents for each search step performed and exit the loop when the first field matches a variable.

(This would require some maintenance for making sure old search criteria is not used.)

3) Move to the destination table and recreate the find steps on layouts in the print file.

This just occurred to me and is similar to an approach I developed a little while ago for creating a dynamic audit trail under v8.5 using object names.

The more I think about it, I will probably go with the latter approach since it will allow me to avoid having to create browse/list/find layouts in the print file just so the user can have the same gui experience...

[Brian C]

My thanks again to you all. If I did not have the opportunity to discuss all this here - I would have stuck myself with a not quite so great approach.

This has opened my eyes to some better alternatives to be sure.

Brian