# Calculation help

## Recommended Posts

I am creating a FM database to track various statistics for golf. Here is what I am trying to do. I have it set up so that each round is a new record. Within each record are scores, number of putts, club used etc, specifically defined for each hole (score 1, score2).

What I want to do is to evaulate each record for how many times a specific club was used, the distance it was used from and weather it was accurate (these are all differnet fields: club1, green1, yardage1...) I want the report to list the clubs along with thre related stats.

Any ideas?

Thanks,

Greg

##### Share on other sites

Hi Greg and welcome.

Your question is a bit of a tall order for a forum such as this in that it has an enormous scope.

I think that I would approach your problem by creating one record for the round with a related table for each hole and then a related table from that to contain the different shots taken for that hole.

This would allow you to allocate the different data that you want to analyse to the relevant area.

Sorry I cannot be more specific but I hope that my answer comes under the heading of any ideas?

HTH

phil

##### Share on other sites

Do a search for your keyword Golf and see what turns up. I remember a couple of discussions along this lines.

Also, I remember a couple of OLD Files at FM Files that maybe of help.

Try doing a search for Golf at www.fmfiles.com, and see what it turns up.

HTH

Lee

##### Share on other sites

But more than one club is used in a round. Consider a table where each record represents a stroke.

##### Share on other sites

Thank all of you for your help. I think the best approach will be to have each hole be a seperate record in a related table. This will make it fairly simple to do the calcs I want to via a portal.

My question now becomes how do I export all the data points I need from the main table to individual records in the second table? I am currently doing this via a script but it is getting a bit cumbersome. Is there a more elegant solution?

##### Share on other sites

I think DavidJ's suggestion is a stroke of genuis.

You'll need a table for each hole (and you could follow through with a table for each course, linked to each hole).

Another table for the club used.

So the Hole table could have one or more Stroke related records. each Stroke related record would have a field for Club Used, Distance, Accuracy, and so on.

You might need to slip a couple of extra join tables in to get the "Round" business happening, but I'll leave that as a exercise for the student.

##### Share on other sites

I think DavidJ's suggestion is a stroke of genuis

I would not question his reasoning nor talent behind, Except attending a bookmaker would tell, that the lions share of questions with "complex calculation" usually falls here, why because Filemaker Inc. have declared this:

When business professionals outgrow spreadsheets, they depend on FileMaker. With ready-to-use applications and solutions, anyone can be more productive

Found here: http://www.filemaker.com/company/index.html

Unfortunately does this in particular lead to a blinkered view - reflected by this:

My question now becomes how do I export all the data points I need from the main table to individual records in the second table?

The issue here is that the entry of data should have been into a structured set of tables right from the beginning ...the next sometimes muffled question, what to do about the lovely calc's already thrown into the solution, in pure eagerness.

The misslead is a deliberate ROI centric behaviour from the marketing geniuses - who fear an too abstract declaration will push a lot of late arrivers right in the ditch, but perhaps as well that these geniuses even hardly can think abstract themselves?

I would raise the point once more, that quite a bit of newbe troubles, in my opinion lies right there, the metaphorical stepstone - and the unhessitant use of the crappy templates included!

--sd

##### Share on other sites

It seems our OP still needs to iron out the details, woodn't you know.

Keep in mind, bushman, your scripted export should only happen once. The data should be entered properly once you get your correct structure. Since the wording of your response is awkward, it's hard to tell if you have an underlying problem with the structure, or if you are just having trouble with converting from the 'old way' to the 'new way'.

Care to mulligan and explain what you're having trouble with?

##### Share on other sites

David,

Thanks for your response and you time to try and help a duffer like me. I am still setting everything up so nothing is set in stone as of yet. I have used related tables in many of my past projects but not to try something like this.

What I was trying to ask to get at was..

I want to have the user enter the data only once as if they were filling out a scorecard: 1 record in the "Main" Table for each round played. From that entry I want to create 18 unique records in a separate related table (one for each hole) with several data points in each record (hole number, club used, etc).

How do I make that happen?

I suspect this is a total noob question and I am sorry to waste your time if it is. I have a moderate amount of experience in FMPro but have obviously not tackled this issue before.

##### Share on other sites

So, nobody got the golf puns: "stroke" of genius, "follow through"...

##### Share on other sites

"I suspect this is a total noob question..."

Well, not really. The golf database that you ask for is actually quite complicated. It needs quite a bit of thought and even more experimentation.

My son was telling me last night how the Concorde (the aircraft) gets a foot longer while in supersonic flight due to heat expansion. Apparently a foot-wide gap opens up behind the bulkhead in the cockpit, and on the last-ever Concorde flight one of the cabin crew stuck their hat into the gap while it was flying, and now the hat is permanently stuck there.

And I got to thinking, sheesh, imagine being the designer of the Concorde and having to remember to allow for a foot of heat expansion in the design of the plane, and working out where it's going to go to (and how many other things are like that, that only happen under extreme operating conditions). And then I thought, sheesh I wonder how many earlier supersonic jet planes fell out of the sky because the engineer *didn't* allow for a foot expansion.

Database design is a bit like that. You've got to know what to allow for, and where to allow for it. And you've got to put the time in to learn what the operating conditions are going to be.

##### Share on other sites

This fella got it right away, and fell off his eucalyptus in sheer happines, or was it to seek shelter for occational golf balls?

--sd

##### Share on other sites

I figured it all out and have it all up and running now. It was actually a very simple thing to do in retrospect. All I had to do was create related tables from the main data set with the club number defining the relationship. I set up one for each club club and each hole. This made a large number of tables but made it easier to manage the data. From here it was just a matter of simple math to get the desired results. Now I can look at my gold data and know exactly how accurate I am with each club and from what ever yardage range I want to look at. Beautiful!!!

Thank you to those who were helpful.

And to those who were not, Soren, I hope you found some joy in your tangential, unhelpful and largely cryptic diatribes. Just a helpful to you for the future: If you don't want to help then don't get involved. I am sure you offer some great value to this community given your senior status here however it was certainly lost on me.

Greg

##### Share on other sites

Thank you to those who were helpful

and...

What I want to do is to evaulate each record for how many times a specific club was used

Alright this is unfortuantely fundamentally wrong, such info should be stored in records in plural ...is it still too cryptic???

--sd

##### Share on other sites

Agree that the templates are terrible. I'm ashamed for FMI that their Time Card example uses repeating fields. Absurd.

## Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×

• ### Who Viewed the Topic

1 member has viewed this topic:
cymainformatica
×
×
• Create New...