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

Need advice on scripted finds


new2fmp
 Share

Recommended Posts

Does a scripted Find only apply to the layout that is used in that Find operation? I have a portal on a main screen that I want to use to view fields from what I guess you could call "a set of current found records from TableA". I have a button on that main layout that runs a script that uses another layout to find a set of records for the TableA, but after the script runs the lines in my portal on the main layout are the same. I've used the debug tool to prove that my script is finding the right records plus the other layout shows the right records. Is there a way to connect that portal to the found set that exists on the other layout without having to make a second copy of the table or running two Find operations?

 

I guess what I mainly need to know is how to be thinking about Finds. Does each layout have its own view of the database (for example TableA) that is different from that used by another layout that also uses TableA? If it is a different view, doesn't this mean that every print layout must look up its own data set even when its called from a button on a layout that already had the right data set? I believe answers to these questions will clear up a lot of things for me. Thanks for any help.

Link to comment
Share on other sites

My relationships are pretty simple. I have tables TableMain and TableA.

 

My Main layout is set to get records from TableMain. Then the layout has a portal showing records from TableA.

 

My Secord layout is set to get records from TableA. This is the layout listed in the Find script step.

 

After the Find script runs, I can go to the second layout and see the found set. But back on the Main layout the portal still shows all records, but you're saying it shouldn't. What should I try to change?

Link to comment
Share on other sites

As a rule, relationships ignore found sets. This is a necessity and a blessing - because each user and each window can have its own found set. A portal always shows all related records - regardless of whether they are included in ANY found set.

Link to comment
Share on other sites

Wow, now I'm really confused. It explains some of the things I've seen, but doesn't this really limit how portals can be used since they can't show a found set? Shouldn't there be two versions of portals: Show All and Show Found? Without moving a lot of records from a found set into a parallel table is there any way to build a Show Found portal? I had a really good use for these portals in my database but now I'm not sure they can help me. Thanks for your responses.

 

 

 

UPDATE: OK, I may have found something. I read ahead in a book I have (Using Filemake by Que) to page 462 and found Filtered Portals. Althougn they don't use the current found set for the normal table it sounds like the following would work:

 

Define global versions of the user-entered text strings I was using in the scripted Find, say gTextOne and gTextTwo in TableMain

 

Create a copy of the TableA and make a new relationship to TableMain that only uses the new globals (TextFieldOne = gTextOne and TextFieldTwo = gTextTwo)

 

Change the portal on my Main layout to display records from the new table copy

 

Add the two global fields to my Main layout and have the user type requests into them (this would be the Show Found version of the portal)

 

When the user presses a Done button on the Main layout, a script can set both global fields to the word "all" (this would be the Show All version of the portal)

 

Does this use Filtered Portals the right way? Is there any downside to doing it this way? Is there a better way?

Link to comment
Share on other sites

First off, there is a sense in which portals "show a found set":

 

If you're on a layout belonging to Invoice (every separate record is a separate invoice) and it has a portal at midscreen to a table called Invoice Line Items (where every separate record is a chargeable item on an invoice, with a quantity, item SKU#, item name, unit name, per-unit price, taxrate, and extended price field for each record), and Invoice is linked to Invoice Line Items via Invoice Number (which is unique to each Invoice), then when you do a Find for Invoice #31609, the portal to Invoice Line Items on that screen will show only the line items for Invoice #31609. Because the other ten-zillion invoice line item records are not related to THAT INVOICE, they don't have the matching Invoice Number.

 

That does not, however, mean that you can just Go to Layout [LineItems] and expect to be looking at the line item records for #31609. You won't be (except by coincidence and accident). The Find that you do on the Invoice layout has no effect on the found set in the other table. You would instead do a Go to Related Records [invoiceLineItems, show only related, current record only, using layout "LineItems"].

 

And yes, you can also set up a portal to use as an ersatz Find. Terms you want to search on are entered on the "home" field of the portal relationship (the field in the table that the current layout "belongs" to) and the portal shows all the matching records on the other side of the portal relationship. You can also use Go to Related Record in scripts instead of Enter Find Mode, Set Field [blah::blah, "foo"], Perform Find. But I would not generally describe a portal as being mainly used for finding records. Portals are more often used to enter data of a type that reoccurs over and over again (like line item after line item after line item on an invoice, with each one having a quantity, a SKU#, a price, etc etc), or to display it once so entered.

Link to comment
Share on other sites

Thanks for taking time to respond. Please bear with me as I'm not sure I follow all you are saying (although it will probably help others who are farther along). Are you saying that what I came up with will work? ("an ersatz find") ---- Or to restate my main question:

 

What is the right way to build a portal to view the contents of a scripted Find operation?

Link to comment
Share on other sites

What is the right way to build a portal to view the contents of a scripted Find operation?

 

A find is used to isolate a set of records. Records are viewed as a found set on List, Form or Table layouts. Performing finds, using GTRR (Go To Related) or filtering portals all have their uses - depending upon the need. If you could explain what you are trying to do for your Users -- explained like speaking to someone new at your company and you're showing them the job, then it would help us help you. We can't make the best suggestion unless we know the User view of it. smiley-laughing

 

So what is the User viewing? What do they need to do with this found set?

 

LaRetta

Link to comment
Share on other sites

OK, here's the best way I can explain what I'm trying to do:

 

TableA contains the titles of manuals, plus a 25-word description of what is covered in the manual

[title1] [description1]

[title2] [description2]

[title3] [description3]

and so on

 

TableB contains keywords of FAQs, plus the text of each question

[keyword1] [question1 text]

[keyword2] [question2 text]

[keyword3] [question3 text]

and so on

 

On my Main layout, I want a user to be able to enter a KEYWORD (or part of one) to look for in the titles and keywords above ---- and also (I hope) a TEXT STRING to look for in the descriptions and questions.

 

Then I want to display two portals in the Main layout as follows: The top portal will show any records from TableA that have a keyword match or that match any of the user-entered TEXT STRING. The bottom portal will do the same kind of thing with TableB.

 

The Main layout serves as an overview for a technician to use (along with other data fields). They can make a couple of text entries and find out what information is available in the database. But here's the main benefit that I want to provide: a button on each portal row that goes (with a GTRR) directly to the layout that shows the detail for the record they pick. This seemed so simple when I started and it was easy to build the find scripts or I could have them go to individual layouts. But the button on portal row has become a real problem. Thanks for taking the time to look at this.

Link to comment
Share on other sites

What you are describing will work, loosely speaking, with some caveats.

 

Where are you? What is the native table for the layout you're sitting on? And what field are you expecting your user to type into in order to "enter a KEYWORD"?

 

Let us assume that the native table (or table occurrence at any rate) is Table C, and that the field your end user types in is a global text field, g.EnterKeyWord.

 

Your portal to Table A would be based on the relationship of Table C to Table A established as: g.EnterKeyWord::Title

 

Your portal to Table B would be based on the relationship of Table C to Table B established as: g.EnterKeyWord::Keyword

 

However, you really probably ought to rethink Table A and Table B. I'd do it as a single table with the following fields:

 

Title

Description

Full Text

Keywords

 

(that sure would make your data entry easier, woudn't it?)

 

I would also ditch Table C and just put the global field right there in the same table, and join the table to itself multiple times, which gives you multiple table occurrences —

 

g.KeyWordEntry::Title = ManualEntryByTitle

g.KeyWordEntry::KeyWords = ManualEntryByKeyWords

g.KeyWordEntry::Description = ManualEntryByDescription

g.KeyWordEntry::Full Text = ManualEntryByFullText

Link to comment
Share on other sites

I would not use portals in this situation. I would open two windows (side by side or one above the other) one from each table holding the results of the search as a list. Clicking button in the row (in either window) would be simple layout switch to form view of that specific record. They can even open multiple windows for searching and retain their last found set - techies like multiple windows.

 

But I get ahead of myself ... I see no relationship between the two tables? Do the FAQs apply to all the manuals or do some manuals have differerent FAQs than other manuals?

 

The reason I would shy from portals ... a find is more resource efficient (in this situation) and certainly much easier to build. Dual portals is possible but with 25-word Description and sentence-long Question exploded, I wouldn't want to do it unless a find with dual windows wasn't an option.

 

LaRetta smiley-smile

Link to comment
Share on other sites

To try and figure a way to do this I've made my database fairly simple:

 

TableMain is the top level with related TableA and TableB showing different kinds of information. (TableA and TableB have to be separate in my real database.)

 

KEYWORD and TEXT STRING are global fields in TableMain and the user is on the layout for TableMain most of the time.

 

I do need to solve this for this example of three tables because my finished database may have four or five that need to work like this (sorry it can't be simpler).

 

 

UPDATE: My application uses maximized windows for each layout, so I never open windows within a window because of the way the main window behaves. Sorry to keep adding conditions, but I guess I'm somewhat set on solving what I see as a basic "how to" question. I've read so many good solutions on this forum that I hope I can do as well with this.

Link to comment
Share on other sites

To LaRetta:

 

Thanks for looking at this. Since you said a Find is much more efficient, would it be best to do the Find for both tables and then load the found records into intermediate tables that are used to supply the portals? I don't imagine most searches will return more than 10 or 20 records. I guess I would have to capture the record numbers and use them with the View buttons on the portal rows. I had thought of this early on but decided there must be a better way.

 

UPDATE: I forgot to mention that there is no relationship between manuals and FAQs. They are both sources of information for the user, Their relationships are with MainTable only.

Link to comment
Share on other sites

You aren't going to capture more results via relationship (portal) than via Find. Quite the opposite.

 

Relationships only work for exact matches. Finds match the beginnings of words, one word among many, the beginning of one word among many, wild cards, ranges, whole-word finds, restrictive literal-string finds (like relationships), lesser-than, greater-than, "omit" requests, and any combination of the above in a sequence of multiple-request Finds. Among other things.

 

The Find engine in FileMaker rocks. Always has. One of the undertouted features of FileMaker.

Link to comment
Share on other sites

To AHunter3:

 

Thank you for pointing that out. I think that will tip the scale in favor of the technique I mentioned in the post to LaRetta. I do want to support partial words and text strings and wildcard matches. Even if it's not as efficient, it will allow me to make the user think the portal is doing it all. Maybe Filemaker can add a new feature in the next version: Smart Portals!

Link to comment
Share on other sites

FileMaker doesn't have to add a new feature. It's a feature of Find Mode itself. It's there. It's been there. It's been there for a long long long long time. Use it. Teach your end users to use it.

 

I'm not saying there's no use for "instant find" portals. They have their uses. But they work on the basis of absolutely-identical matches, or, at best, complicated expansions based on calc fields that expand on what you enter, which still must match according to pretty strict parameters that define the match-relationship. A true "Find" is more steps for the user, but it's also a giant HELLO to the sheer power of FileMaker's inherent internal Find mechanism. Learn it, play with it, discover awe for it. It's been what it is since FileMaker 2 days.

 

You may choose to restrict your users' access to it, giving them instead portals to do their (phony-ersatz) Finds, or scripting their Finds and giving them limited-function buttons to invoke those scripts. There are reasons for doing so; I've done it myself. But first know what the native Find engine can do, so you aren't asking how to replicate its very strenghts and features in the structure of some scripted or portal-based workaround that you've devised, or you really end up reinventing a wheel that rolled pretty damn good in its original incarnation.

 

The fundamental FileMaker "Find" puts the SWL Query to shame. Take pride in it; it kicks butt.

Link to comment
Share on other sites

To AHunter3:

 

You've made strong arguments in your posts that show a firm understanding of Filemaker. But this topic has made me realize that there is another force working behind the scenes and that is a simple difference in philosophy. I'm not all that knowledgable with Filemaker (I'm learning), but I've thought a lot about the way software today dumps a lot of technical baggage over onto users.

 

What I see is that they have their jobs to do and they just want the system to present information they need. They really (most) don't want to learn database features. Plus if they're not burdened with the technical side of things, they can spend more of their "mental energy" on doing their job.

 

And we have our job to do, which in my area means to provide them what they need BUT HIDE the nuts and bolts level of the Finds and relationships and the like. As I said in one of my posts, I run my applications in maximized windows so the user doesn't have to fool with managing multiple windows. I also hide the status area and lock the toolbar so there are no Find, Browse and Preview modes for them to worry with. For the function I'm designing now, scrolling through found manual titles and FAQs in portals from the main layout is the simplest way I can think of to deliver results to them.

 

I still think a Smart Portal would be a good addition. The existing Find features are powerful because they have to include all features that are needed to solve a general class of database problems. A Smart Portal could be set up (by the programmer to match the application) so that the user gets 90% of the benefit of the search features with only 10% of the effort. That is the kind of leverage that is has meaning for users. And yes it would be like a second wheel, much like the front wheel of a bicycle has a different purpose than the rear one. (while a really talented person can make riding a unicycle look easy, most of us do better on bicycles!)

 

I respect your opinions and am sure they fit many usage environments. But I will continue to look for ways to hide as much of the technical side of what we do from the user as I can.

 

Thanks for your responses.

Link to comment
Share on other sites

You make some good points, too; and I've designed solutions just as you describe. (I've even been known to yank every available command out of the menus save for "Cut" "Copy" and "Paste").

 

There's always a tradeoff: many of the "nuts and bolts" of FileMaker are pretty user-friendly given a one-day orientation, and an end user who understands how the thing is really working is going to be a better user of the system. On the other hand, if you can create a simpler "front end" without losing too much power, that can make end users' live easier.

 

I have a solution that has Clients and Vendors and potential Clients and plain-vanilla "Rolodex" name/address entries in one table, and contact people for any of the above in a portal on their data entry pages going to a second table. I have a page called "SuperFind", which does two things:

 

a) "Instant Find", which is the portal-match. A string typed in the single glboal "Find-it" field instantly matches telephone numbers, addresses, names, cities, states, zip codes, and the matches themselves are divided up into different portals so the end user sees whether the match is a match on primary record or on contact person, and whether it's name/address or telephone/zip/ or whatever.

 

b) On the same page, there's a button that automates (and hides the complexity of) a complex find — it lets the user queue up multiple requests, make "omit" requests, and specify whether the Find is to include Clients, Vendors, Rolodex entries, and/or the Contact People for same. It executes in a long series of loops that cover a wide range of possible Find parameters and assembles the results in a list view.

 

I admit it's not quite as simple and intuitive as the "Instant Find" portal-thingie, but its pretty accessible for what it does.

 

So I guess what I'm saying is not "end users should just learn how to use the built-in tools in their raw state" but rather "for complex finds, the thing I would start with to create an easy-to-use 'front end' would not be the portal but the Find engine".

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