I'm new to FM, and am not sure how to best approach the following
need.

I've taken the contact mgt DB template that ships with FM8.5, and
modified it a bit to use as a 'party management' system for a big
event we're having.
So I've added fields like # of guest invited, are they coming Fri
night and / or Sat night, are they out of town, how many hotel rooms
are needed, relative or friend, etc. All of these fields are either
defined as #'s or text pull downs with pre-defined lists. There's no
chance for variation in say, how 'friends' is spelled.

I need to make the viewing of the data really easy for my wife... I'd
like to modify the list view, so that it has a pull down menu where
she can choose view by...
- and see just relatives, just friends, just out of town, just those
needing hotel rooms, just those Sat night etc.

I'm NOT trying to do a sort, where it shows me all records, sorted by
these fields. I want to just see those records who meet the criteria
for the view by choice.

How best to build that functionality ?

Thanks!

<rgarber (AT) mac (DOT) com> wrote:

I did this by defining a browser-like quichsearch interface. On your
layout(s) have a global text entry field, preferably formatted as a drop
down list with a custom value list, and a <Go> or <Search> button next
to it. This button calls a script that finds the chosen item in a
"quichsearchdata" calculated text field. You define the calculation to
fill this field with the necessary items derived from your data fields.
Like: relation & <P> & If(outoftown, "out_of_town") etc. etc.
(The <P> stands for the pilcrow, the paragraph character from your
calculation dialog)

On Apr 19, 1:13 pm, jri... (AT) xs4all (DOT) nl (Hans) wrote:
Just be aware that its terrible database design from a modelling
perspective.

If you have a table of people:

first name, last name, out_of_town, gender, age, searchfield

and search field is defined as:

first name &P
last name &P
out_of_town &P
....

You effectively have field in your record that is a copy of several to
most of the other fields. Worse, its stored and indexed that way.

Its the sort of thing that makes database designers coming from SQL
cringe.

A much 'better' way, from a data modelling perspective is to define
separate relationships, and then use a tab control or multiple layouts
to display the right portal.

That said, I understand the appeal of multiline keys used like this,
and agree that it can lead to a more flexible user interface. But if
you are working on a big database, its the sort of design choice that
can turn a 3GB file into a 6GB file.

I'm not saying never do it, I'm just saying be aware that its a
hideous solution in terms of what it does to the data model, and if
you are going to do it, you should be aware of it.

Cheers,
Dave

d-42 <db.porsche (AT) gmail (DOT) com> wrote:

True, but a bit academic. Generally in this kind of solution the
duplicated data are a small part of the record, and are not being stored
in an unconnected place so you don't have data update troubles. As the
poster said he was new to FM, I might add as a general remark that in
Filemaker development you sometimes have to bend the rules of data
modelling a little bit to achieve a practical solution. But Dave is
right of course: know what you are doing and why you are doing it.

--
Hans Rijnbout
Utrecht, Netherlands