You can add fields from other tables to any type of view, Form, List, or Table. Just go into Layout mode and add the fields.
When you add a field to the layout, the table (or, more precisely, table occurrence) from which they come can be selected using the pull-down at the top of the field list:
If you like, you can automate the Find using a script, which works fine in WebDirect.
If they're related tables, you can just display the related fields in a standard list or form view, making them searchable. Without a portal, you'll just see the first related record's data in browse mode (same as what you saw in table view). You just have to have them placed on the layout for your user to begin with, because they can't be added on the fly.
So while it is possible to do your complex find (EG find mode itself is perfectly capable), your use case requires the much more robust table view with allowances for schema and layout changes, which at this time is only a feature of FileMaker pro/pro advanced (FMGo has a stripped down version of table view that doesn't allow customization).
The lack of table view is covered in the WebDirect guide, along with other caveats of WebDirect:
Jive really needs a live refresh feature!
I think she was aiming more for the ability to modify the fields list on the fly. To get a layout where the parent and all related subtables' fields are present, you'd have to drop a LOT of fields onto a layout. This would almost certainly negate a list view, and could be a poorly performing form view in WebDirect due to the amount of objects (assumably hundreds of fields).
Incidentally, this could be a potential feature request for WebDirect.
Hm. Maybe I read it wrong.
In that case, perhaps a scripted approach might work, but it would be complicated. What about putting the fields in the off-screen area on a Form view?
Then a user wouldn't be able to type in those off-screen fields for their own find request. The other thing to do would be to have "start find" / "perform find" buttons that took a user to the complex layout only in find mode, which would at least save the data loading complication. However since it was also noted that exporting was required, that might not work either.
TL;DR - WebDirect isn't exactly the filemaker pro thin client replacement that people think it is (yet).
Yeah, you're right; what I had in mind was globals combined with the offscreen fields.
You might could use a scripted approach using globals and selectors for which fields to search in. Would take some work to set up, but it might work.
How many searchable fields are we talking about here, Laura? A couple of dozen? A couple of hundred?
I don't mean how many possible searchable fields, I mean "How many do actual people actually use to do actual Finds?".
So we obviously don't need to use hundreds of fields for a search, perhaps around 10. The problem I think is that this could be a different 10 fields depending on the person performing the find and what they are interested in, and the number of possible combinations is huge. As you can't change the layout and add these fields in using webdirect, I can't see how people would be able to do that.
As Mike B and I were discussing, it's possible if you use a dedicated search screen. You can have a series of global fields in pairs, with a field name in one and the search string in another, then parse it out using a script. You capture the field name and the search string, then enter Find mode and use Set Field By Name to insert the values the user entered into a number of Find requests equal to the number of fields they completed.
Takes a bit of setup, but it can be done.
I think that the 2 Mikes are onto the most feasible approach, Laura. This may be one of those cases where the path to success doesn't lead directly thru FileMaker but rather makes use of your external expertise on operational procedures. Conduct a survey of your users to find out what fields they actually do search on, in real-world practice, then build a dedicated search screen to include those fields, grouped in some logical, orderly fashion, and have them run all their Finds from there. You will undoubtedly have to add more fields later (because that's just the way things are), but adding a few extra fields to a layout that's already 90% complete should be less tooth-gnashing than what you're currently going thru.
Why not just show all the fields available. You can separate them by table onto different tabs or popovers to make their management easier and improve performance.
If certain users are only interested in certain data, you can make layouts specifically for those users with their required data.
Please note, in your post, you're frequently using the term "layout" incorrectly. You want to be able to show fields from other "tables" on your current layout.
Thanks for the suggestion, the problem is that my knowledge is far too limited to even begin to know how to do that. I understand what a global field is and some of what you're saying, but I don't have any experience with anything like this, nor do I have access to someone else who does.
Then I'd say you're best off going with the dedicated search screen that has on it only the actual fields you expect anybody to do searches on. (They don't all have to come from the same table.) Write a script that (a) remembers where you were when the script is invoked, probably by a button click; (b) takes you to the search layout; and (c) goes directly into Find mode, letting your users enter their criteria. Then you can either (d) have the script finish off by returning where it came from or (e) have it display the results of the Find along with a button that accomplishes the return. In either of the latter 2 cases, you'd want to trap for the condition of FoundCount = 0.
Sadly providing a search screen with dedicated fields just isn't feasible. We have hundreds of fields and there are no common fields that people may wish to search for. I would end up needing to adjust this screen for each person every time they wanted to search the database. I think our best option is that we all use the computer with FileMaker pro installed to perform a search.