From: Tara on
John & Ken,

I didn't see your posts until just now. Not sure what happened, however they did not come through for some reason. All 3 of you (including Jeanette) agree that it's a bad idea to do what I was going to with the multiple yes/no fields. Looking back on it, your right, not the smartest thing I've come up with. That having been said, I am very intrigued by both of your responses to my question. I'm going to have to look into what you are saying, but I think I understand what you gentlemen are getting at and will play around with the database to see what works best. For now I can't thank all of you enough for your wise council. It's been a huge help!
Tara



KenSheridan via AccessMonster.com wrote:

Tara:I will come back to the question of having a single 'InstallType' column
27-Jan-10

Tara:

I will come back to the question of having a single 'InstallType' column later,
but firstly I'd like to examine just how the survey data is stored. I am
assuming the form is based on a 'Jobs' table or similar, so lets assume it
has a primary key JobID. What I'd envisage for the surveys is a Surveys
table which includes a foreign key JobID column to relate it to the Jobs
table. This table would have a primary key SurveyID and columns for those
attributes which are common to both types of survey, such as SurveyDate. As
the two survey types presumably each have attributes which are distinct for
each I'd then envisage two further tables, ContractorInstallSurvey and
InHouseInstallSurvey say, each of which will again have a primary key
SurveyID. The important point here is that the SurveyID columns in
ContractorInstallSurvey and InHouseInstallSurvey are also foreign keys
referencing the primary key of Surveys, i.e. the relationship type is one-to-
one. Note that the SurveyID columns in ContractorInstallSurvey and
InHouseInstallSurvey cannot be autonumbers, but that in Surveys can be.

For data entry I'd envisage a form based on the Jobs table and within it two
subforms, one for each survey type. The ContractorInstall survey subform
would be based on a query which joins Surveys and ContractorInstallSurvey on
SurveyID, the InHouseInstall survey subform on a query which joins Surveys
and InHouseInstallSurvey on SurveyID. Both would be linked to the parent
form on JobID.

You could either superimpose the two subforms and show the relevant one.
With your current two fields you would put the following code in the AfterUpdate
event procedures of both check boxes bound to these fields, and in the form's
Current event procedure:

Me.sfcContractorSurvey.Visible = Nz(Me.ContractorInstall,False)
Me.sfcInHouseInstall.Visible = Nz(Me.InHouseInstall,False)

where sfcContractorSurvey and sfcInHouseInstall are the names of the subform
controls in the main form, i.e the controls which house the subforms.

The reason for the Nz functions is that when you navigate to a new record a
bound check box is Null until you start to enter data.

The other option would be to have both subform's visible side by side or one
above the other, or on separate pages of a tab control and enable/disable
them as appropriate. In this case the code in the event procedures would be:

Me.sfcContractorSurvey.Enabled = Nz(Me.ContractorInstall,False)
Me.sfcInHouseInstall.Enabled = Nz(Me.InHouseInstall,False)

Coming back to the issue of a single 'InstallType' field rather than your two
Boolean (Yes/No) fields I'd agree completely with Jeanette and John on this.
What you are doing at present is what is known as 'encoding data as column
headings. A fundamental principle of the database relational model (the
Information Principle) is that data is stored as values at column positions
in rows in tables and in no other way.'

What I have said above about the survey tables and subforms would still apply,
however. You'd just amend the code along these lines:

Me.sfcContractorsurvey.Enabled = (Nz(Me.InstallType,"") = "Contractor")
Me.sfcInHouseInstall.Enabled = (Nz(Me.InstallType,"") = "InHouse")

Ken Sheridan
Stafford, England

Tara Metzger wrote:

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-gettingstarted/201001/1

Previous Posts In This Thread:


Submitted via EggHeadCafe - Software Developer Portal of Choice
C#.NET and COM Interop
http://www.eggheadcafe.com/tutorials/aspnet/917881ce-7228-4b0c-8610-bc2550430968/cnet-and-com-interop.aspx