Conventions for Naming Fields

[Jarvis]

I'm not sure where to post this question so I thought I would start here.

I'm building a list of questions that I have to ask each customer.

For lack of a better way to do this, each question is also the field name.

(I am going to try to integrate LaRetta's field factory for this purpose).

Each question that I ask has a value list associated with it that constains the range of allowable answers.

This list of questions will be lengthy so I would like to also include an identification number for each question. I think it will be easier to manage this list if I can point someone to "question 26" if that question still remains unanswered.

I would like my field names to be similar to the following:

(1) What is the finished floor to ceiling height?

(2) What is the desired height from finished floor to top of countertop?

(3) blah blah blah, etc.

When I try to include bracketing () around the numbers I get an error message that says the inclusion of said bracketing will make it difficult to include the field in calculations later on.

Does anybody have a suggestion to work around this?

Thanks,

Jarvis [color:"red"]

[LaRetta]

Hi Jarvis!

Well, I see where you are going with this but I think a standard questionnaire style relationship with each Survey a table, each question a table and each answer a table would 1) be easier to work with and 2) provide much greater flexibility and reporting options for you. Listing questions as fields is indeed tempting. It isn't until you have to split this type of structure into records (because it is almost useless) that the problems will become clear. We'd be happy to point you to some ideas for a questionnaire structure if you wish.

Having said that, if you still wish to proceed, you might consider storing the REAL question name (including the question number) into the field comment as it will take anything. It is easy to get via FieldComment ( fileName ; fieldName ). However, you wouldn't be needing these questions in calculations anyway so getting the error you receive really shouldn't be a problem. All you would/could do with them is concatenate them (and why would you need to?).

Either way you go, I wish you well.

LaRetta

[Jarvis]

LaRetta,

Thank you for responding so quickly!

I know the answer to my question is sitting somewhere in your response.

I just have to stare at it a little longer.

You wrote:

" I think a standard questionnaire style relationship with each Survey a table, each question a table and each answer a table would 1) be easier to work with and 2) provide much greater flexibility and reporting options for you."

Did I just read you to say that each question should contained in it's own table?

I would welcome any ideas you have for questionaire structure.

What I am trying to do write down every question that I have ever asked a customer.

I am trying to get it so that when you walk into my showroom I can ask a few questions to establish which list of subsequent questions I should be focusing on.

For example: If you want painted cabinets, we don't need to discuss stain grade issues.

If you want natural finish cabinets, we need to be talking about whether you want slip-match or book-match veneer.

I never get to sell a kitchen without asking every question.

If I can remember to ask them in the right sequence things go smoother.

(Way better to ask while the customer is in the showroom and you can point to something than when they are on a cell phone on the way to the airport!)

I'm also trying to do this in some kind of format where the data is separated from the question.

My apologies for this ramble.

I'm just now returning from a hiatus in Filemaker so I'm struggling a bit getting back up to speed.

I appreciate your patience.

Jarvis

[transpower]

It's not good practice to have spaces in field names or tables; you'll run into numerous problems later on. If you're serious about programming conventions, take a look at the FileMaker Pro Development Standars by Core Solutions, Inc. Their URL is www.coresolutions.ca/.

For field names, I go from general to specific, start with lower case and then add uppcase to distinguish the parts. For example: addrBillCity, addBillHouseNumber, addBillState, etc. I also segregate user fields from developer fields, by starting each developer field with a "z".

[Jarvis]

Thanks Transpower!

I will take a look at that link.

Jarvis