Dynamic Dropdown Lists

#11

In article <Es2dnVXDbccUexTYnZ2dnUVZ_h-3nZ2d (AT) comcast (DOT) com>, "Bill
Marriott" <wjm (AT) wjm (DOT) org> wrote:

<snip>

Quote:

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.)

He wants the field to be a dynamic drop-down list rather than static
one.

The system works, is easy to use, etc. and is the way you have to do it
in FileMaker. Whether or not it conforms to some magical standard for
SQL systems is irrelevant really - it's definitely not "wrong", just a
different way.

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

#12

Simply put: the objective of a good OLTP design is the elimination of
redundant information.
The fact that I have to create 'duplicate' information (just to
populate the dropdown), violates basic relational design.

As an aside, and is an error made by most people using RDBMSs, ER
diagrams are NOT relational algebra. This has been pointed out in many
ACM/IEEE and textbooks for quite a while.

As for 'relational correctness being overrated'. If that were true,
then no vendor would have the ability to query the database, and if
they did, there would be no guarantee that the queries would even
operate equivalently (which they sometimes don't, because of vendors
interpretation of nulls and various syntax differences due to how the
vendor implemented their systems). That's why the X3.135 standard is so
important.

Dr. Joe

Quote:

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 in message
news:1166660648.173860.282760 (AT) i12g2000cwa (DOT) googlegroups.com...
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:
In article <1166573928.432362.163900 (AT) n67g2000cwd (DOT) googlegroups.com>,
"JoeT" <trubisz (AT) yahoo (DOT) com> wrote:

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.

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)

#13

I'm not sure what the issue is here. Can't you simply create two table
occurences (not new tables, but new occurences) of Table R, relate them
to each other and define a value list off that?

New fields:
global storage set by script or by calc = 2 and 3
g2, g3

New TOs:
vlTableR1, vlTableR2

Relationship:
vlTableR1 b =g2 vlTableR2
vlTableR1 c=g3 vlTableR2

Value List
Defined based on field vlTableR2 using only related values from
vlTableR1.

G

JoeT wrote:

Quote:

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

#14

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

Quote:

Simply put: the objective of a good OLTP design is the elimination of
redundant information.
The fact that I have to create 'duplicate' information (just to
populate the dropdown), violates basic relational design.

Please stop whining on about it. As I've already sai, every system is
different and has quirks of it's own, and there is no magical
"standard" for how to do anything ... and even if there was Microsoft
would be breaking every rules there is to do things their own way
anyway.

The information is not "redudnant" - you want it displayed in a
drop-down list then that information MUST be stored somewhere /
somehow.

You also don't have to "duplicate" anything - if the data already
exists then you can probably simply create the appropriate
relationships within the existing tables.

Again, simply because you're new to FileMaker and it does things
differently to which ever system you used before doesn't mean it's
"wrong".

I really beginning to think that either you didn't give enough
information in the initial question (VERY often the case) or are simply
using the wrong application and should go back to whatever
super-magical "correct" system you were using before.

\

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

#15

I agree. If the only way to create a filtered drop down list was to
create a second table and populate it with duplicate values, that would
be pretty lame. Thankfully, that's not the case.

I don't think the Dynamic Value List example offered in the link is
what you're looking for.

G

JoeT wrote:

Quote:

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:
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:

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

#16

I took a look at the sample file.

As I suspected, this is merely an issue of how the designer set up the
tables, and not an inherent issue within FileMaker. Additionally, this is a
good example of where "over-engineering" a solution simply for the sake of
meeting some idealized alphabet soup of standards makes little sense.

The original poster was complaining that the sample file has "duplicated"
information. This is merely for convenience and simplicity. The "List" table
in this example contains a "Primary" and "Secondary" field. The Primary (or
"parent") field has Beatles, Bird, Vegetable, and Car repeated.

This could alternately be set up with a "join" table which would abstract
things a level further to use IDs instead of names for the parent groups. It
would have made the solution a lot harder for new users to understand, but
it would have been "correct."

Again, this is not a limitation in FileMaker -- it's just the way it was set
up. Similar "violations" could have also been made using MySQL or Access.

"Helpful Harry" <helpful_harry (AT) nom (DOT) de.plume.com> wrote

Quote:

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

Simply put: the objective of a good OLTP design is the elimination of
redundant information.
The fact that I have to create 'duplicate' information (just to
populate the dropdown), violates basic relational design.

Please stop whining on about it. As I've already sai, every system is
different and has quirks of it's own, and there is no magical
"standard" for how to do anything ... and even if there was Microsoft
would be breaking every rules there is to do things their own way
anyway.

The information is not "redudnant" - you want it displayed in a
drop-down list then that information MUST be stored somewhere /
somehow.

You also don't have to "duplicate" anything - if the data already
exists then you can probably simply create the appropriate
relationships within the existing tables.

Again, simply because you're new to FileMaker and it does things
differently to which ever system you used before doesn't mean it's
"wrong".

I really beginning to think that either you didn't give enough
information in the initial question (VERY often the case) or are simply
using the wrong application and should go back to whatever
super-magical "correct" system you were using before.

\

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

#17

Now i get it!
Thanks for the tip!

Joe

Grip wrote:

Quote:

I'm not sure what the issue is here. Can't you simply create two table
occurences (not new tables, but new occurences) of Table R, relate them
to each other and define a value list off that?

New fields:
global storage set by script or by calc = 2 and 3
g2, g3

New TOs:
vlTableR1, vlTableR2

Relationship:
vlTableR1 b =g2 vlTableR2
vlTableR1 c=g3 vlTableR2

Value List
Defined based on field vlTableR2 using only related values from
vlTableR1.

G

JoeT wrote:
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

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Dynamic Dropdown Lists

comp.databases.filemaker comp.databases.filemaker

Re: Dynamic Dropdown Lists - 12-20-2006 , 11:31 PM

Re: Dynamic Dropdown Lists - 12-21-2006 , 08:43 AM

Re: Dynamic Dropdown Lists - 12-21-2006 , 12:13 PM

Re: Dynamic Dropdown Lists - 12-21-2006 , 01:56 PM

Re: Dynamic Dropdown Lists - 12-21-2006 , 05:20 PM

Re: Dynamic Dropdown Lists - 12-21-2006 , 05:30 PM

Re: Dynamic Dropdown Lists - 12-21-2006 , 06:01 PM