Conditional record veiwing

[Rainy Pass]

In simple terms I have a To Do file that I want to use to view all the completed items on one layout. I would like to view the "To do" items on another layout. I though I could do this without scripting but, so far I have not got it to work. Can someone help me set this up.

[mz123]

Is there a reason you're avoiding scripting?

You could create a script as follows...

Go to Layout ["To Do"]

Enter Find Mode

Set Field [Complete ; "*"]

Omit Record

Perform Find

Sort Records

or

Go to Layout ["To Do"]

Perform Find //The criteria would be the Complete field and you would put "==" as the search criteria/

Sort Records

Does that help at all? If not, maybe we could see your file?

[Rainy Pass]

Thanks for the reply

I guess it was a futile attempt to understand the limits of relationships a little better.

I opted out and chose to script it.

[Baloo]

I’m attempting to do the same thing. If I can get it to work I’ll post an example file if not I’ll probably still post to see if someone else can give it a try.

There are several reasons why I’d prefer to use a relationship to limit records with a view over a scripted find. Primarily because with the view there is no chance that the user will inadvertently override the found set. It also cuts down on the amount of scripting needed to maintain the view (e.g. The user could just ctrl F and stay with-in the limited set without needing to remember or even know they need to constrain the set).

Edited to add: What I'll probably wind up doing is normalizing the table out into one main table for most of the data and several smaller tables with a 1:1 relationship and only the fields I need to force the view. But it seems like I should be able to accomplish the same thing with a self join.

Edited June 12, 2007 by Guest

[Baloo]

After playing around with this for a few days I finally wrapped my head around the idea that "table references" aren't views. They are just references to tables and if you look at them directly (i.e. set a layout to show records from them) you get the entire set of records, even if you set up some funky self relationship in an attempt to filter them down.

Note to Filemaker Inc. I for one would love to be able to create Views and add them to the Relationship diagram.

If you want to build your to do file and have one layout only show "completed” items and another only show "to-do" items you'd need 3 tables.

Task (PriKey TaskID), Completed (PriKey TaskID), ToDo (PriKey, TaskID).

When you create a record in Task create a record in ToDo. When you complete a task delete the record in ToDo and create a record in Completed.

So essentially you’re trading one set to enforce reading of scripts for another to enforce writing. Which is better will depend on your requirements. If we had Views it could all be based on data entry.

limitedView.zip

Edited June 18, 2007 by Guest

[comment]

We have views - they're called portals.

limitedView.fp7.zip

[Baloo]

Portal <> View

A View can stand on it's own; a portal requires a parent record.

So you can't build an entire layout around a portal.

You also can't (or rather shouldn't) print from a portal.

[comment]

Is there a parent record in my file?

You can print from a list view. You should do a find before you print. Finding is also another way to view only records of a certain type.

[Baloo]

Is there a parent record in my file?

Yes 7 off them showing exactly the same data.

If you had Views you’d have one layout with two Proposed records, one layout with 3 In Progress records and one layout with 2 Complete records and one layout with 7 task records all reading from the same table. Not one layout with 7 records containing the same list with variable content.

You can print from a list view. You should do a find before you print. Finding is also another way to view only records of a certain type.

But what if the business rules state that users should never be able to see record subset A on layout 1 and users should never see record subset B on layout 2? Portals are not Views they can be kludged to function sort of like views, but suppose you don’t want a list you want a form and let me reiterate allowing the user to select show all records, or run their own find then display an invalid record on the layout goes against the specifications for the project so scripting a Find is not an option.

[comment]

I guess our definitions of "parent record" differ. But that is beside the point. Actually, I am not sure what the point is. Filemaker does not do things your way. It's still possible to implement all the business rules you have mentioned. I grant you it's going to take some work, if you want to marry a layout to a type. But that's rarely necessary - in most cases, all it takes is a couple of extra fields, which can be hidden or shown using the "visibility" trick, for example.

In any case, managing a duplicate set of data is not the answer.

[Baloo]

It’s a problem that frequently crops up for me. (For what it’s worth all my solutions track scientific data.) The visibility trick is how I got around the problem in FMP 6 (“invalid” records went blank except for a button to the correct layout) with the migration to 7/8 I was really hoping base it solely on a relationship.

In any case, managing a duplicate set of data is not the answer.

If you take a closer look at my example the only data that is being duplicated is the Primary Key of the main table. A task list is probably not the best case scenario for this method, but it was in the first post.

I’m currently implementing it for a “sample” table. There are pure samples and rough samples, and samples do not move between the two conditions. Their history and attributes are the same and a business decision was made to use the same ID for both. So storing them in the same table makes sense, however pure samples are rigorously QC’d (described in downstream tables), and rough samples are not. Both are used in scientific analysis and are produced/managed by the same lab. Needless to say that lab in no way shape or form wants rough samples to be confused with pure ones, hence the need for separate layouts. I have a sample table that stores all the data and keeps the ID, then PureSample storing only the SampleID and RoughSample storing only the SampleID.

[comment]

I am not objecting to the data model you have described on principle. The question is what drives the adoption of this data model: is it the nature of the data itself, or is the need to control the user interface? Letting user interface dictate the data model is the equivalent of shooting yourself in the foot. Especially in Filemaker, where producing a union report can be a nightmare.

If the data belongs in the same table, it should be in the same table. The navigation problem can be solved by scripting the user interface entirely, and eliminating all built-in navigation and searching tools - especially Show All Records.

[Baloo]

The data is in the same table. The satellite tables just contain the Key ID the main table has all the data and can function as your "Union". It's also worth mentioning that a View can also represent a Union of tables and not just a subset of one. So there's one more reason for Filemaker to consider supporting them.

Yes you can achieve most if not all of this by scripting everything and removing all control from the user, but at least for us that defeats the main reason we still use Filemaker for about 1/2 of our database needs (as opposed to porting everything to PHP/MySQL) speed and ease of development.

[comment]

I think most of the developers here have expressed, at one time or another, their preference to script user navigation entirely. And it's not like your method is scriptless. But there is a big difference: scripting the navigation does not affect the data in any way. I don't like having data integrity depend on the success of executing a script.