Adam,
I get individual emails from the Yahoo Group and none of the previous thread is included in the email I received. The entire email is listed below. My replies (using Outlook.com) by default include the previous content from the thread.
It's not "what Roger calls" but what I call SurveyID since it is my demo application. I would still attempt to work with a normalized table structure even if the response table needed to have separate fields for text, numeric, or memo data types. It might take some additional work to handle this but IMO would be a good investment. I do have another sample database on Rogers site for employee evaluations http://www.rogersaccesslibrary.com/forum/employee-evaluation_topic15.html.
I understand your limitations so my thoughts are simply academic. With the current solution you are working with it seems like there is a lot of busy work creating controls for each field both on forms and in reports. In addition, if questions are added, removed, or modified it will require design changes. A normalized solution would typically require maintaining data, not design.
Duane Hookom MVP
MS Access
To: MS_Access_Professionals@yahoogroups.com
From: runuphillracing@yahoo.com
Date: Thu, 27 Mar 2014 02:56:59 -0700
Subject: RE: [MS_AccessPros] Too many fields defined
Duane,
Doesn't Yahoo Groups include the thread? It does for me.
Re RogersAccess sample, each question as a new record: That doesn't make sense. The responses are different types: text, numeric, memo, binary. Why would I want them all to be 255 char text fields? The InterviewID (what Roger calls SurveyID) is the primary key. Each interview, set of responses, is a record.
Also, as I mentioned before, I'm just mentoring the person doing this. I'm not being paid nearly enough to completely redesign his database, even if I thought this was the right way to go. I gave him guidance to include InterviewID in ea table, how to link them via queries, and ways to tighten up the field names and properties. That's about as much as I thought he was capable of handling, both in terms of Access ability, and time.
What I did was break the query up into 7 pieces (there are 8 tables), with two tables in each (tbl1, and then each of the subsequent tables), linked by InterviewID. I created a "main" report with qry1 as its source, with 6 subreports, linked by InterviewID. The reports are just shells for now. He has to add the content for each, using templates I created for him for the different types of ways the output is presented (i.e., the output isn't simple field1, field2, etc., but a series of paragraphs that combine conditional text and conditional boiler plate based on the answers).
Thanks
Adam
I get individual emails from the Yahoo Group and none of the previous thread is included in the email I received. The entire email is listed below. My replies (using Outlook.com) by default include the previous content from the thread.
It's not "what Roger calls" but what I call SurveyID since it is my demo application. I would still attempt to work with a normalized table structure even if the response table needed to have separate fields for text, numeric, or memo data types. It might take some additional work to handle this but IMO would be a good investment. I do have another sample database on Rogers site for employee evaluations http://www.rogersaccesslibrary.com/forum/employee-evaluation_topic15.html.
I understand your limitations so my thoughts are simply academic. With the current solution you are working with it seems like there is a lot of busy work creating controls for each field both on forms and in reports. In addition, if questions are added, removed, or modified it will require design changes. A normalized solution would typically require maintaining data, not design.
Duane Hookom MVP
MS Access
To: MS_Access_Professionals@yahoogroups.com
From: runuphillracing@yahoo.com
Date: Thu, 27 Mar 2014 02:56:59 -0700
Subject: RE: [MS_AccessPros] Too many fields defined
Duane,
Doesn't Yahoo Groups include the thread? It does for me.
Re RogersAccess sample, each question as a new record: That doesn't make sense. The responses are different types: text, numeric, memo, binary. Why would I want them all to be 255 char text fields? The InterviewID (what Roger calls SurveyID) is the primary key. Each interview, set of responses, is a record.
Also, as I mentioned before, I'm just mentoring the person doing this. I'm not being paid nearly enough to completely redesign his database, even if I thought this was the right way to go. I gave him guidance to include InterviewID in ea table, how to link them via queries, and ways to tighten up the field names and properties. That's about as much as I thought he was capable of handling, both in terms of Access ability, and time.
What I did was break the query up into 7 pieces (there are 8 tables), with two tables in each (tbl1, and then each of the subsequent tables), linked by InterviewID. I created a "main" report with qry1 as its source, with 6 subreports, linked by InterviewID. The reports are just shells for now. He has to add the content for each, using templates I created for him for the different types of ways the output is presented (i.e., the output isn't simple field1, field2, etc., but a series of paragraphs that combine conditional text and conditional boiler plate based on the answers).
Thanks
Adam
__._,_.___
| Reply via web post | Reply to sender | Reply to group | Start a New Topic | Messages in this topic (7) |
.
__,_._,___
Tidak ada komentar:
Posting Komentar