Professional Web Applications Themes

Portability of field descriptions? - FileMaker

This may be stupidly simple or an opportunity for a developer... I use FM 5.5 (Mac) to tabulate online survey results, converting answers, counting results and calculating percentages. Each new survey means tons of new filed definitions (usu. about three per vairable). I was wondering if there's a way to make field definitions 'portable', i.e. to copy them from database to database - what I'd like to get to is a point where I'd set up 'generic' field definitions with the conversions/counts/calculations required that I'd simply need to 'cut' and 'paste' into each new database (and only have to make ...

  1. #1

    Default Portability of field descriptions?

    This may be stupidly simple or an opportunity for a
    developer...

    I use FM 5.5 (Mac) to tabulate online survey results,
    converting answers, counting results and calculating
    percentages. Each new survey means tons of new filed
    definitions (usu. about three per vairable).

    I was wondering if there's a way to make field definitions
    'portable', i.e. to copy them from database to database -
    what I'd like to get to is a point where I'd set up
    'generic' field definitions with the
    conversions/counts/calculations required that I'd simply
    need to 'cut' and 'paste' into each new database (and only
    have to make minor changes to variable names).

    Is this even possible?

    Ron Levesque

    Ronald Guest

  2. #2

    Default Re: Portability of field descriptions?

    Ronald Levesque <com> wrote:
     

    Well, you can always Save a Copy As of the database, choosing Clone, and
    then modify the new file field definitions. Then what you end up with is
    a separate database for each survey's results. Is that truly what you
    want? For most people, this kind of "organization by filename" data
    structure ends up being a dead end, as they cannot then compile summary
    reports across files, find data within their file set easily, or
    navigate within their data files.

    What you might consider is that for the fields with variable
    definitions, you place the variables into reference fields in another
    file. So if a field has a multiplication factor, for example, that
    varies from survey to survey, you put that multiplication factor in a
    reference file, and look it up as the current survey records are
    created. Build your field definitions modularly, by referencing fields
    which hold the variable factors, and then you don't need new files for
    every new survey.

    This is a technique I use for clients, so that they can administer their
    own "variable" data, such as mileage allowance amounts, part markup
    amounts, etc. Those things which might change in the course of business
    are in reference fields, not hard-coded into the field definitions. That
    way they don't need to call me every time they increase a bonus rate or
    California changes all the county tax rates (again!).

    Lynn Allen
    www.semiotics.com
    562.938.7890
    Lynn Guest

  3. #3

    Default Re: Portability of field descriptions?

    Working off clones is what I'm doing now...and if the survey is similar to
    the cloned one, it's not bad, but...

    Because I work with different types of questions - some simple 'yes' or
    'no' questions, some multiple choice, some on a 5 or 7 step Likert scale,
    etc, the ideal situation would be to be able to copy, for example, a set of
    field definitions for a 7 step Likert scale that converts the answers to
    countable values, counts them in a running total summary and then figures
    percentages (a total 21 field definitions in this case) and only have to
    change part of the variable name to reflect perhaps the Question number,
    i.e. "Q3aAgree_strongly" for the first instance in question number 3... I'd
    like to be able to copy a whole block of definitions and then paste them in
    my survey database, and only have to change small parts of the variable
    name...

    Ron Levesque

    Lynn allen wrote:
     
    >
    > Well, you can always Save a Copy As of the database, choosing Clone, and
    > then modify the new file field definitions. Then what you end up with is
    > a separate database for each survey's results. Is that truly what you
    > want? For most people, this kind of "organization by filename" data
    > structure ends up being a dead end, as they cannot then compile summary
    > reports across files, find data within their file set easily, or
    > navigate within their data files.
    >
    > What you might consider is that for the fields with variable
    > definitions, you place the variables into reference fields in another
    > file. So if a field has a multiplication factor, for example, that
    > varies from survey to survey, you put that multiplication factor in a
    > reference file, and look it up as the current survey records are
    > created. Build your field definitions modularly, by referencing fields
    > which hold the variable factors, and then you don't need new files for
    > every new survey.
    >
    > This is a technique I use for clients, so that they can administer their
    > own "variable" data, such as mileage allowance amounts, part markup
    > amounts, etc. Those things which might change in the course of business
    > are in reference fields, not hard-coded into the field definitions. That
    > way they don't need to call me every time they increase a bonus rate or
    > California changes all the county tax rates (again!).
    >
    > Lynn Allen
    > www.semiotics.com
    > 562.938.7890[/ref]

    Ronald Guest

  4. #4

    Default Re: Portability of field descriptions?

    Ronald Levesque <com> wrote:
     

    Oh. That explains it more clearly.

    Since there are a limited number of TYPES of surveys, I would build a
    file for each type. So you could have one file for your 5 or 7 step
    scale, and another for simple YesNo answers, and one for each other
    significant type. You can still use the reference field idea, in that
    you can specify how many of the scale fields are evaluated dynamically
    by your processing scripts or calculations, so you can use the same file
    whether your scale is 3, 5, 7, 9 or more.

    The field names would be quite generic (Q01, A33, etc). Then I would
    make variable *labels* for each field, which are what specify what each
    question & answer MEAN. This way, the setup for a new survey would be
    quite simply a matter of text entry.

    BTW, have you taken a look at http://www.wmotion.com/dragon.html ? Your
    survey product could already be built, and very reasonably priced, given
    the features included.

    Lynn Allen
    www.semiotics.com
    562.938.7890
    Lynn Guest

  5. #5

    Default Re: Portability of field descriptions?

    The 'file' idea is what would work best IF I could copy field definitions from
    each type of question and paste them into my current survey...sort of building
    a whole with 'already built' pieces. I think I'll have to keep working the way I
    am...

    And I did look at Dragon surveys a while back and it didn't seem to give the
    flexibility I was looking for (that's my recollection). In my surveys, I can
    basically search on any field to get results for a given variable. An example is
    'Results for everybody' by finding all records, 'results for males' by doing a
    find on the gender field or 'Results for females' by doing the same find with
    the value for females...by doing two finds, you can even go deeper and find
    results for 'females' and then people aged '25-34' from within the first found
    set....

    Ron Levesque

    Lynn allen wrote:
     
    >
    > Oh. That explains it more clearly.
    >
    > Since there are a limited number of TYPES of surveys, I would build a
    > file for each type. So you could have one file for your 5 or 7 step
    > scale, and another for simple YesNo answers, and one for each other
    > significant type. You can still use the reference field idea, in that
    > you can specify how many of the scale fields are evaluated dynamically
    > by your processing scripts or calculations, so you can use the same file
    > whether your scale is 3, 5, 7, 9 or more.
    >
    > The field names would be quite generic (Q01, A33, etc). Then I would
    > make variable *labels* for each field, which are what specify what each
    > question & answer MEAN. This way, the setup for a new survey would be
    > quite simply a matter of text entry.
    >
    > BTW, have you taken a look at http://www.wmotion.com/dragon.html ? Your
    > survey product could already be built, and very reasonably priced, given
    > the features included.
    >
    > Lynn Allen
    > www.semiotics.com
    > 562.938.7890[/ref]

    Ronald Guest

Similar Threads

  1. Asp Object descriptions showing on design page
    By tshad in forum Dreamweaver AppDev
    Replies: 0
    Last Post: April 26th, 03:45 PM
  2. Design mode descriptions
    By tshad in forum Dreamweaver AppDev
    Replies: 0
    Last Post: April 22nd, 05:46 PM
  3. Macromedia program descriptions and uses?????
    By Sean in forum Macromedia Freehand
    Replies: 0
    Last Post: February 13th, 02:50 AM
  4. Portability
    By Yomna el-Tawil in forum PERL Beginners
    Replies: 2
    Last Post: November 19th, 06:54 PM
  5. PHP Portability Tip
    By Google Mike in forum PHP Development
    Replies: 1
    Last Post: October 13th, 03:18 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139