Hi...

MacOSX FM8.5 Adv

This is a much simplified example of the real problem.

I have a table, R, with fields a,b,c.
I want to populate a dropdown in a layout with the value of R(a), when
b=2 and c=3.

Is this even possible?

TIA,
Joe

Dynamic value lists are a matter of setting up relationships to control what is displayed.

Perhaps the demo Dynamic Value List at http://www.virtualvermont.com/FMP might help...

Matt

On 12/18/2006 09:43:34 "JoeT" <trubisz (AT) yahoo (DOT) com> wrote:

OK...this is what I did come up with.
But, what you are saying is that I have to maintain another table of
values, which in actuality, is a subset of the data that appears in the
master table.

For example, if I have table R, I have to create a table S, containing
the values that I need to populate the dropdown with. Personally, that
a pretty lame technique. Regular SQL databases don't need this at all.
Seems to be something lacking in FileMaker.

Joe


Matt Wills wrote:

In article <1166485762.029904.321190 (AT) n67g2000cwd (DOT) googlegroups.com>,
"JoeT" <trubisz (AT) yahoo (DOT) com> wrote:

Yes, you do have to have a separate table for the pop-up menus /
drop-down lists if you want them to be dyanamic. It makes it very quick
and easy to add, edit and remove values. It's also very simple and
utilises one of FileMaker's standard abilities rather than tacking on
yet another way of doing something.

Since I've never actually used it I have no idea about SQL, but from
the VERY brief look I did have a long time back it seemed extremely
painful and clumsy to be able to do anything even very simple. It's
really a matter of opinion and what you're used to - no doubt some
idio... err, nice people, prefer Access.

Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

The fact that I have to maintain a separate table to do this is plainly
wrong, just from a relational database point of view. In any IEEE X3
database, I would never have to do this.

To address your statement below, if I use HTML+/Perl/PHP/Javascript+any
RDB, this is a trivial thing to do. No need for accessory tables and I
can actually do a SELECT DISTINCT, something I have found is another
'hoop' you need to jump thru when using FM.

Joe


Helpful Harry wrote:

In article <1166538148.729559.258950 (AT) i12g2000cwa (DOT) googlegroups.com>,
"JoeT" <trubisz (AT) yahoo (DOT) com> wrote:

It's not "wrong" by any stretch of the imagination (except your own).
It's simply a different way of doing it ... and again one that many
people find MUCH easier to understand and use. FileMaker's method uses
a standard existing feature of FileMaker that doesn't need to add a
more complicated method / functions. It works, it works well and it
works easily ... pretty much the trademark of FileMaker. It also makes
it very easy for a developer to allow the user to change the options
themselves (if needed).

As I said, I have never used SQL or web-database systems. From the
quick look I did have they seemed an extremely painful way to do
anything remotely simple ... especially when compared to a system like
FileMaker Pro. "Select Distinct" will probably need all sort of
background "hoops" that have to be set up first.

And as for "hoops", every product ever made has it's own "hoops to jump
through". You've simply learnt one method on one system and now you
need to learn another on a new system - one that's not highly taxing to
do either. Access may well have a third different method. If I had a
reall need to I could learn SQL and would find all sorts of "hoops" and
silly ways of doing things simply because I've been using what is
probably the easiest, and yet very comprehensive, database system yet
made.

Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

Personally, and being a newbie, I really like FileMaker.
My only complaint is that there are many 'missing' elements in the
system, which are much better implemented using standard SQL and make
data integrity much more robust.

If I was a person at FileMaker and had the opportunity (or interest) in
reviewing this particular newsgroup, I would be concerned about issues
many people have had regarding the ability to perform even trivial
functions and have them addressed in future versions of the system. I
know this because in searching for HOWTOs in implementing some
function, it's always been something like having the secret decoder
ring or the special handshake to find a solution.

I guess my issues revolve around FM saying they support the relational
model, yet, in reality, their support of the model is very primitive at
best. I'd spend time making sure that they address those issues. If
they did, the functionality of the system would be far easier to use
and would most likely address many of the concerns of other users
encountering the same problems over and over again.

Dr. Joe.


Helpful Harry wrote:

In article <1166573928.432362.163900 (AT) n67g2000cwd (DOT) googlegroups.com>,
"JoeT" <trubisz (AT) yahoo (DOT) com> wrote:

You're a FileMaker "newbie" so you have to learn to use the new
product. All the different database products work differently and have
different strangths and weaknesses, but none of them is "wrong". Some
are more complicated, some are more powerful, etc. FileMaker is
designed to be an easy to use system that's highly flexible ... and is
VERY successful at that task.

It's not as if it's so hugely complicated to create a new table for
dynamic pop-up menu fields - in fact in many ways it's the most obvious
way of doing it.

Try doing anything in Access and you'll see how difficult even simple
database creation can be.


Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

It might not be as easy to create a table in access as FM, but it is
relationally correct, something that FM doesn't seem to understand too
well.

Put it this way: if one of my students handed in a design using FM, and
told me that it was correct (using the method necessary to create the
dropdowns), they would definitely lose points in database design.

Like I said: it IS a good system; it's the odd limitations which
confuse me.

Joe

Helpful Harry wrote:

I'm not sure what you're talking about. FileMaker schemas can be set up just
as correctly or incorrectly as in any other RDBMS. The "relationships" tab
in Define database is very similar to, but not exactly like, the traditional
data model graph. It operates at a more pragmatic, as opposed to abstract
level.

You're specifically criticizing "the method necessary to create the
dropdowns" yet I know of at least two ways to do this, so without specifics
I'm not sure how you're saying it breaks the rules. (Value lists aren't even
part of the core RDBMS definition.)

"Relational correctness" is over-rated anyway. The only reason databases
exist is for people to accomplish real-world tasks. If a system works to get
something done (e.g., make a profit in your business) then who cares if it's
truly relational or pseudo-relational? Having said that, FileMaker and
arguably be said to satisfy the majority of Codd's 12 rules ... not even
MySQL or Access strictly adhere to all of them.

I don't know of a widespread commercially successful product that IS a
*true* RDBMS; every system out there has departures, and often for good
reasons. It's mainly an issue of which variation you prefer... and for some,
what is preferred is merely what is familiar to them.


"JoeT" <trubisz (AT) yahoo (DOT) com> wrote