Multi-key adjustment

[Daniel Shanahan]

I have a simple db - two tables. The db keeps track of a tennis league. Players may play Singles or Doubles matches. In the Match layout I have a multi-key field that relates to the primary key of the Player field (_fk__Player_id and _pk__Player_id respectively). This enables me to show the match info in a portal on the Players layout for the two or four players involved in the match (depending on Singles or Doubles match).

I have a Cartesian join, enabling me to show all the players while on the Match layout. A button on that portal populates the fields Player_1, Player_2, Player_3, and Player_4. At the same time, the multi-key match field is also populated. All of this works fine.

However, what if someone makes a data-entry mistake. I would like the user to be able to undo or remove the data from the player fields (Player_1, Player_2, etc.). This also works fine.

What I want to know is how to remove the associated Player_id from the multi-key field. For instance, if John Doe (whose id # is 1) is removed, how do I remove his id (#1) from the multi-key match field?

In the event that my explanation is convoluted, I've included the file.

Thanks.

dan

Tennis.fp7.zip

[Søren Dyhr]

Although I dissagree with the overall relational structure, could you as a quick fix change the multilinekey into a repeating field, since it simplifies the scripting, and the behaviour is exactly the same as a multilinekey relational speaking.

But strictly speaking should an invisible button be above the single double radio button pair, to clear the two last repeaters.

--sd

TennisMod.zip

[Inky Phil]

Time for a new monitor. This one must be broken.

No matter how often I read that last post I could swear that Soren advocates the use of a repeater.

:laugh:

[Søren Dyhr]

For utility purposes only, with a disclaimer that it only is a fix, and a more normalized solution should be pursued. There is no crusades agains utility uses ...from my side.

This is a keyfield, and we used it a lot under fm7 before custom functions turned up. At this day of age would I probably utilize:

http://www.briandunning.com/cf/39

But a quick look at the theething the scripting exhibited, turned me away from it. There are several flaw in the reasoning presented, the area where the match flow is set should be a portal...

With a layer TO sanwiched in to keep the positions, where an ordinary portal will roll up if the topmost is deleted. The approach should follow this approach:

http://www.fmforums.com/forum/showtopic.php?tid/176396/post/204083/hl//fromsearch/1/

---------------------------------------

Meanwhile have I toyed a little with the method found in JMO's thread - it might still have some quirks, but as proof of concept might it be enough?? The prevention of double booking is not as neat as I could have wished it to be!

--sd

tennisSD.zip

Edited August 23, 2007 by Guest

[Daniel Shanahan]

Thanks Søren. I will have to study the db you sent. I am fairly new to the concept of having a "Viewer" or User Interface that completely uses related fields. I like the concept - its just that it is new for me.

Also, I'm curious about the aversion to repeating fields. I understand they break normalization. However, in PHP arrays are common.

dan

[Søren Dyhr]

Let's take a look at what is written about PHP's arrays:

Arrays support both numeric and string indices, and are heterogeneous. Arrays can contain elements of any type that PHP can handle, including resources, objects, and even other arrays. Order is preserved in lists of values and in hashes with both keys and values, and the two can be intermingled

What does it sound the most like when speaking filemaker'ish, records or repeating fields?? How would you with repeaters define a repeat of repeaters, only utilizing repeating fields, in my opinion does records of a table seems most like the PHP array!

Normalization is not the devils reading of the bible, plucking among excerpts suiting a specific purpose's chosen vanity. Normalization deals with classical database problems ...which only due to the pretty flat learning curve of filemaker as tool initally can be believed ignored. As tasks gets more complex the less are you chances into getting away ignoring theory actually is existing.

You might originate from a background, where beleives matters more than knowledge and mathematical proff, which makes you take on a teory and ditch it as you pleases...

But you should then brush up on why then the rest uf us attempt to normalize in the first place:

http://en.wikipedia.org/wiki/Database_normalization

--sd

[Daniel Shanahan]

Let me step back to the "Viewer" concept that you posted (tennisSD.zip above). In that example there is a "Viewer" Table with no fields and one record and all the other data is viewed in the Viewer.

Are there any white papers, articles or chapters in books where I can read more about this method?

d.

[Søren Dyhr]

Not directly, but it builds on this:

http://www.digfm.org/ref/FM7_key_concepts.pdf

...and this:

http://www.newcenturydata.com/downloads/fm7_rel_1.pdf

--sd

[Søren Dyhr]

Try to read this as well:

http://fmcollective.com/2007/04/30/just-add-the-table-already/

--sd

[Daniel Shanahan]

Thanks. If you (or anyone else reading this) run(s) across any documentation on using a recordless table for a UI, I'd love to have a copy.

[Søren Dyhr]

Correction, it's not recordless - at least one record needs to be created!

I think you will search forever for documentation covering the use of a fieldless viewer table, it just occured during the debate in the calendaring thread.

I think Comment came up with it, becasue he didn't like the vast amount of prefab records required to deal with plannig for a certain timespan. When turning into an cartesian related set of records acting as placeholder instead of an arbitrary measure of prefab record, turned the calendar into one with beginning or end.

There is a small price to pay, by the use of calc'fields adjusting the keyvalues instead of the prefab'ed ...namely the rendering gets a tad slower and you would see a burst in the CPU utilization graph!

But what it on a more general level is about, is that you could make a relation to each cell, but it's much slower than this approach originally suggested by JMO.

Similar would you have lots of difficulties in tracing down documentation of what we here calls Ugo's method, which a lot of us use for portalized summaries...

--sd

[Daniel Shanahan]

Matt Petrowsky just released a video on this topic. See Seperation-Model

[Søren Dyhr]

No not really, the tunneling of values is the issue in both of course but what the video is about is two files, one without fields ...but a big difference is if you turn on the status area.

Here will counters deal with the referenced files records in the SM, where mine only would need one record, and similar is the rolodex daft to get some usefull knowledge out of.

But since you're mentioning Petrowski video, would this one be much more relevant for the understanding of the method I utilize:

http://www.filemakermagazine.com/videos/graph-rules-four-rules-to-remember.html

--sd

[Daniel Shanahan]

Thanks, Søren. That video is a nice reference.