Jump to content
Salesforce and other SMB Solutions are coming soon. ×

Need help with Finder Table Occurrence


new2fmp
 Share

Recommended Posts

I have what I know is a basic question, but it has me stumped for three days now. I created a table occurrence to use as a "finder" table (like the book says) to use with one of my data tables. It contains a global field that I set equal to the value that I'm trying to find in the data table, and the relationship is defined as =. The finder table works (it locates all the records I want, although I only know this by having it look up different values).

 

The problem is on the display side. I built a layout to show records from the finder TO, also like the book says. The individual fields on the layout are showing data from the data table. The layout displays the first record only. My Go To Next Record button does nothing. The status area only shows that there is one record so that probably is trying to say there is only one finder record, which is true. How should I have set up the layout so that I can step through the found records? I will certainly appreciate getting some help past this point -- or maybe point me to an example. Thank you.

Link to comment
Share on other sites

I don't have your book. Can you explain what you did and what you were trying to do when you did it without explaining it in terms of "I did the thingie like the book said"?

 

I don't know why you would need a "finder table". I suppose that's a vlable way to do it, but I'd just create a global field in the table that has the records I want to "find" in this manner, and then create a self-join relationship between the global and the field I want it to match.

 

LAYOUT

 

|-----------------|

|..global field....|

______________

 

=====portal======

 

Matching Record 1

Matching Record 2

Matching Record 3

Matching Record 4

=============

 

 

On each line of the portal, alongside of the fields I'd put in the portal to distinguish the matching records from each other, I'd put a tiny button that has a script attached that does this: Go to Related Record [selfJoin, using layout "DataEntry for that Table"]

 

When you click the button, your found set would consist of all of the values that had matched what you put in the global, and you'd be specifically ON the one record you'd clicked on in the portal.

 

Now, you can do that with a separate table but I don't see the utility of doing so.

Link to comment
Share on other sites

Thank you for the information. The book I have is FileMaker Pro 8 The Missing Manual. On page 372 in the Advanced Layouts section they describe "Creating the Invoice Finder". They specifically say "since the global fields aren't associated with any particular table, you can create a new table to hold them. They use as examples: Start Date, End Date and Minimum Amount. Unfortunately they leave you hanging with respect to how to construct the layouts that they show.

 

I'll work toward understanding your suggestion and will try to test it tomorrow. The layout that I need to display results on won't work well for me if it is a portal. I can, however, set up a portal as a way to get to my real layout. But when I'm there, I need to be able to step forward and backward through the qualifying (found) records.

Link to comment
Share on other sites

Yes, it will work for that. The portal will show you all the matches, then when you click the button on any given portal row, with the script I described above, it will take you the layout you do want to be on, with all the other matching records being either before or after the record you end up on (which will be whichever one you clicked on).

Link to comment
Share on other sites

I kept after it tonight and got it to work like you said (using a portal and GTRR as a way to call my layout). My first attempt at the GTTR only resulted in viewing one record -- but then I found the Match All Records in Current Found Set option. Now it all works. Tomorrow I'll try to understand why my original approach stayed locked onto only the first record. But at least I have a working result I can move forward with. Thanks very much for your guidance on this.

Link to comment
Share on other sites

I have the Missing Manual book and I reviewed the section you are referring to. Do you have the sample files from the book? You can download them from the web link on page xxiii.

 

You said:

"The problem is on the display side. I built a layout to show records from the finder TO, also like the book says. The individual fields on the layout are showing data from the data table. The layout displays the first record only."

 

That's because you are displaying only the first record of the relationship. To see more records from that layout, you need a portal (as the book has).

 

Also you said:

"My Go To Next Record button does nothing. The status area only shows that there is one record so that probably is trying to say there is only one finder record, which is true. How should I have set up the layout so that I can step through the found records?"

 

You are correct - you are seeing the one record from the "Invoice Finder" table. You could display all records in a portal. Or you could use a button to Go to Related Records which can then jump to the Invoices layout for you.

 

I have attached a modified finished example from the book. What I have added is what you probably need - button(s) to jump to the related records of the relationship. This is what AHunter is referring to.

 

AHunter is also correct when he said "Now, you can do that with a separate table but I don't see the utility of doing so." But I would suggest that the benefit of doing it the way the book details may be to shield the user from the actual invoice records while finding because you are operating from a related table record that means nothing to the data. It is a small thing but I have seen people question why there are 400 records in the "invoice finder" and go ahead and delete them only to find all the invoices have disappeared.

Link to comment
Share on other sites

Well I have had fairly good success at getting the results I was hoping for -- but there are a couple of relationships I have not been able to make work, so I've have prepared this simple version of my database in hopes that someone can point out the two remaining flaws. (I have circled the problems in red on the two layouts.) I do want to confirm something, however, to make sure I am on solid ground:

 

THE REASON I was setting up these Find Tables was so that certain data sets (views?) that are used in several different processes are clearly defined and always available to any layout or script that needs them, which is what I interpreted the book to be saying. I didn't want to have to script a lot of Finds throughout my application. Am I correct in thinking this is a good usage? Or am I asking for problems in areas that I can't see yet?

 

SECONDLY, is there a simple rule of thumb on setting the Show Records From for single layouts that show fields from different tables. As my example shows, I can't get a portal to display sometimes ("layout unable to display results") with a Go To Related Record. Should it always be set to the "highest" table?

 

That's about it for now. I will appreciate any additional help on this.

 

 

BTW, I forgot to mention that the reason I want to use "blank" as an indicator for a suspended order is that the user can simply blank out the field and store the record. Blank seems natural for "unassigned".

Link to comment
Share on other sites

OK. You have a lot of structural issues in there! I have reviewed the file and updated it with comments on the layouts. Have a look and see if you can understand where I am coming from.

 

You have not really used the Find table in the way that the book suggests. I have used (new) globals in the Location table since your portal filters were oin layouts based on that table.

 

See what you think.

Link to comment
Share on other sites

Thank you for the update. I have worked with your file and have these comments and questions:

 

All Orders -- OK, I see how that works. You created a copy of Orders that essentially says it is NOT related to a specific location, so no filtering takes place.

 

Unassigned Orders on Main -- I also see your approach, but I'll need to change it over to _LocStatus and set Statusfilter to show only New since it is now showing both New and assigned.

 

View Orders for Individual Technician -- this seemed to be working properly and you didn't change it, so is it a proper use of the relationships? By the way, the way I think about these global fields is that they are used to "nail down" particular fields to specific values and then all records containing those values are "found". Is that a reasonable way to think of them in this use?

 

And as I said before, my whole reason for doing it this way is to set things up once, so that other layouts and scripts will be able to depend on the contents of these base tables -- or table occurrences, I guess. Is this reasonable?

 

One more point is that I am also trying to make my database understandable when I show it to others, especially non-programmers. I thought my original find tables had clear identities and purposes and I can't say I see how they were very different from those in the book. But I do see how your changes work and see how they can eliminate one level of tables. Based on any answers to the above or further suggestions I will rework my file and post it for another quick review to see if I have what I think I have. That probably sounds like I'm confused, but I think I'm close on this.

Link to comment
Share on other sites

Here is my updated file that I feel is much simpler.

 

I have defined two different globals for New and Suspend. My reasoning is that I can nail down the contents of two different subsets of Orders and use them on the same layout if I want. The values are hardcoded but can be changed if ever needed. I know that the Next and Previous buttons are not needed but I run my application with the Status Area hidden. I also made a slight change so the View Suspended shows suspended orders for all locations not just one.

 

My only question is why can't an empty field be used as a way to find a suspended record. I know what you are saying about why to use something like "Suspend" but I'm curious about the empty field. I just doesn't work. Actually one blank works, but an empty field doesn't. Is there a rule or something about this?

 

I would appreciate any other suggestions anyone has about the results of my changes.

Link to comment
Share on other sites

This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



×
×
  • Create New...

Important Information

Terms of Use