We have Questionnaire that I thought I'd input into filemaker to get
the results but I've decided that my filemaker skills aren't up to it.

I thought the easiest question to start with would be male or female
but can't even work out how best to set it up and then come up with a
percentage of male and female that filled in the questionnaire.

This is the first of about 15 questions does anyone have any ideas or
suggest a template that might get me started.

Thanks for your time.

In article <1180502190.073532.322560 (AT) x35g2000prf (DOT) googlegroups.com>,
info (AT) earthgarden (DOT) com.au wrote:

Although it can be done (and I have done it in the past), FileMaker
isn't really the best place to do data analysis. You're much better off
using a spreadsheet application like Excel which is purposely designed
for number-crunching and graphs.

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

In article <1180502190.073532.322560 (AT) x35g2000prf (DOT) googlegroups.com>,
info (AT) earthgarden (DOT) com.au wrote:

Filemaker can store the data and generate numbers from analysis of the
data.

Filemaker is not ideal for doing graphs, which are best for visual
presentation of data analysis, though it can be made to do graphs by
various tricks. However, the numbers generated from FileMaker can be
exported to a spreadsheet application to make graphs.

To generate the numbers, you can use Summary fields, or a relationship
structure and aggregate fields based on the relationship.

For example, to count occurrences of Male or Female in a Gender field,
you could define a summary field as

SummaryCount(Gender)

Then make a columnar report/list layout with a subsummary part when
sorted by Gender, and put the SummaryGender field in that subsummary
part. Then when you sort the records by Gender and print (or view in the
Preview mode) the count of each gender will show up.

To export the subsummaries to a graphing application, you would need to
further define a GetSummary field that would generate the numbers in a
way that is suitable for export or use in other calculations.

You can also set up related tables and define fields that use the Sum or
Count functions to pull those aggregates from the table holding the data.

You could use a spreadsheet instead of FileMaker for this, but I prefer
to use FileMake, as I think FileMaker provides greater protection of the
integrity of the data. I also find the calculation capabilities of
Filemaker to be powerful and versatile.

--
For email, change <fake> to <earthlink>
Bill Collins

info (AT) earthgarden (DOT) com.au wrote:
This can be done quite well imho and is quite fun to do . I suppose we are
not talking about 10.000+ questionaires so the amount of data is limited and so
data-structure does not have to be perfect (at first), brute force is a good
way to enslave your copy of FileMaker. I don't know your basic level of
FileMaker and what I suggest might not work in your particular case but here
are my two cents ...

Just begin with creating a single table called 'questionaire' that will hold
the answers of your questionaire. Create fields with readable names or even use
the whole question. Also include a field with a record-id and some fields which
can help you to enter comments etc. you can use these yourself during
processing and don't have to show up in your presentations.

Also create some unstored calculated fields:
recordFoundCount = Get ( FoundCount )
recordTotalCount = Get ( TotalRecordCount )

Enter a couple of questionaires in the rough layout FileMaker presented to you
and then re-arrange the layout, create some valuelist etc. to help entering the
data. It might help to enter a comment with these records to mark them as 'test
records'. Enter a couple more records

The whole idea with most simple stats is that you count the number of records
that contain a certain value and use that number in further calculations. To
get those numbers I mostly use relationships.

Say you have a field 'questionaire::gender' containing the value 'Male',
'Female' or 'Unknown' and you would like to get the numbers... (Since
relationships to empty fields are more elaborate I suggest you always enter a
value in every field)

Create a new instance of the 'questionaire' table and name it
'questionaire_by_gender' and create a relationship 'questionaire::gender =
questionaire_by_gender::gender'. Create an unstored calculated field
'genderCount = questionaire_by_gender::recordFoundCount' and place the new
field on your layout and check its value. It will contain the number of records
that have the same value in the 'gender' field as the record you are in right
now.

Now create a new unstored calculated field 'genderPercentage = 100 * (
genderCount / recordTotalCount )' and place it on your layout. It will contain
the percentage of questionaires that have the same value in the 'gender' field
as the record you are in now.

Go back to database design and create a global calculated field 'constanteMale
= "male"' and create a new instance of the 'questionaire' table and name it
'questionaire_are_male'. Create a relationship 'questionaire::constanteMale =
questionaire_are_male::gender' and create an unstored calculated field
'genderCountMale = questionaire_are_male::recordFoundCount' and place the new
field on your layout and check its value. It will contain the number of records
that have the answer "male" in the 'gender' field.

Now create a new unstored calculated field 'genderMalePercentage = 100 * (
genderCountMale / recordTotalCount )' and place it on your layout. It will
contain the percentage of questionaires that have the value "male" in the
'gender' field.

…

It was a bit lengthy but I had some spare time and I hope it will give you a
headstart.

In article <465d87bb$0$22156$dbd45001 (AT) news (DOT) wanadoo.nl>, Sargasso
<no.way (AT) ho (DOT) se> wrote:
Well, IF you call creating LOTS of extra fields and trying to debug
them "fun", only to then be told you need to add "just one more
question" ... then I suppose it is. )

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

Helpful Harry <helpful_harry (AT) nom (DOT) de.plume.com> wrote:
What is more fun (except the obvious) then to create a small custom
application in FileMaker that makes the people upstairs happy. When properly
created and with some export to Excel for the graphs you can expect to see the
results of your labor throughout the whole company.

In article <465e1e46$0$56250$dbd4b001 (AT) news (DOT) wanadoo.nl>, Sargasso
<no.way (AT) ho (DOT) se> wrote:

In which case it would have been easier to just use Excel from the
start. ;o)

It greatly depends on what type of results you want out of it
(percentages in particular can be painful to set up). In my experience
I've found it better to use Excel, unless it's something you're going
to be doing quite often for the same questionnaire and then it MIGHT be
a good idea to use FileMaker - once you've spent the hours setting it
up it can easily handle the task of collating the replies ... but think
ahead!!

I have one database system I regularly use to collate answers
(including simple bar charts) from two questionnaires, but it only
handles up to 10 respondents. Although that is usually enough for each
group, there are sometimes groups with a few more that the database
can't handle and it would be a waste of a lot of time to try and add
to. (I do these manually and then create a report in PageMaker
instead.)


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

Helpful Harry <helpful_harry (AT) nom (DOT) de.plume.com> wrote:
I do not fully agree with you on this, Excel is very handy because of the
document-linking possible from with Word documents used to create the reports
but to create the data subsets I prefer FileMaker. It is one thing to get the
most simple stats but try to envision things like the relation between 'male
respondants, older then a certain age, living in a certain city or area with
more then a certain number of pets' and 'male respondants without pets but
spanish speaking' (I know it is a bit ...)

What I normally do is create the database, let somebody enter the data and then
perform the finds etc. to do the real statistic research and then bring only
just enough results to Excel to make the chart. This way the management can
play around in excel without messing up the actual figures.

But hey whatever ways brings the result!

BTW: Happily harassing helpfull humans again?

In article <465eb1dd$0$73089$dbd49001 (AT) news (DOT) wanadoo.nl>, Sargasso
<no.way (AT) ho (DOT) se> wrote:

Believe me, it's still a lot easier in Excel - the problem is that most
people simply don't know how to use Excel to do much more than total
columns. Excel functions like CountIf make it very easy to do what you
want.

If all you need are simple Summary reports, then FileMaker is fine, but
it's once you start delving into percentages and things that it can get
messy very quickly.

Basically Excel is designed to do number crunching, whereas FileMaker
is designed to do data storage. Using FileMaker to do semi-complicated
data analysis is a little like trying to use a screwdriver to put in a
nail ... it can be done, but it's far easier to use the tool designed
for the job. )

The reverse is also true. Excel can do some database functions and can
be programmed to act quite nicely as a database / "custom application",
but realisticially it's much easier to do that in a FileMaker database
(or even Access if you must).



That's where you Lock the cells or simply copy the chart's numbers to a
separate file ... AND you never give them the real file anyway, just a
copy of it. )


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

Helpful Harry <helpful_harry (AT) nom (DOT) de.plume.com> wrote:
I have been teaching Excel for a couple of years so don't start with me on
that, I know what Excel can do. If you would like to do it completely in Excel
its fine with me. This is a FileMaker forum and FileMaker is more then capable
to do the job in a fast and elegant matter. I finished with the whole
discussion "database vs spreadsheet" 15 years ago.