fields

I would like to create other subfileds after answering a yes/no question so
once a answer has been choosen, then other type of fields appear to be
answered. For instance, if the answer is yes, then another field name or
sames appear.

There are no such objects as "subfields". Why not just use tables, fields,
and records as provided by Access?

--
Duane Hookom
MS Access MVP
--

"Miguel Vivar" Miguel wrote in message
...
I would like to create other subfileds after answering a yes/no question so
once a answer has been choosen, then other type of fields appear to be
answered. For instance, if the answer is yes, then another field name or
sames appear.

"Miguel Vivar" Miguel wrote in
message ...
I would like to create other subfileds after answering a yes/no
question so
once a answer has been choosen, then other type of fields appear to
be
answered. For instance, if the answer is yes, then another field
name or
sames appear.

Miguel Vivar,

Is there a chance you are referring to Controls on a Form, and general
formatting of Forms, etc.?

If so:

microsoft.public.access.forms
microsoft.public.access.formscoding
microsoft.public.access.formsprogramming

All exist to cover Forms issues.

If I am wrong about this being about Forms, I apologize.

Tables do not dynamically self-alter based on changes to the data they
contain. You could, in theory, create a Form that, when a control was
checked off, would trigger an Event and VBA code running in the Event
could execute some DAO code to alter a Table. However, I must most
strongly recommend that you do not do so. Now, altering the
appearance of the Form based on a control that is checked would be
completely ok.


Sincerely,

Chris O.

Duane Hookom wrote:
I would like to create other subfileds after answering a yes/no question so
once a answer has been choosen, then other type of fields appear to be
answered. For instance, if the answer is yes, then another field name or
sames appear.

Perhaps this will give the OP some ideas:

CREATE TABLE Questions (
key_col INTEGER NOT NULL UNIQUE
)
;
CREATE TABLE Answers (
key_col INTEGER NOT NULL UNIQUE
REFERENCES Questions (key_col)
ON DELETE CASCADE
ON UPDATE CASCADE,
data_col VARCHAR(20) NOT NULL
)
;
INSERT INTO Questions VALUES (1)
;
INSERT INTO Questions VALUES (2)
;
INSERT INTO Questions VALUES (3)
;
INSERT INTO Answers VALUES (1, 'Don''t know')
;
INSERT INTO Answers VALUES (3, 'Can''t say')
;
SELECT Questions.key_col,
IIF(Answers.data_col IS NULL, 'N', 'Y') AS has_been_answered,
Answers.data_col
FROM Questions LEFT JOIN Answers
ON Questions.key_col = Answers.key_col
;

I just want to say that for me at least it is bewildering the way you
present a suggested table design. I wouldn't know where to run that code,
or why I would prefer it over design view.

wrote in message
oups.com...

Duane Hookom wrote:
I would like to create other subfileds after answering a yes/no question
so
once a answer has been choosen, then other type of fields appear to be
answered. For instance, if the answer is yes, then another field name
or
sames appear.

Perhaps this will give the OP some ideas:

CREATE TABLE Questions (
key_col INTEGER NOT NULL UNIQUE
)
;
CREATE TABLE Answers (
key_col INTEGER NOT NULL UNIQUE
REFERENCES Questions (key_col)
ON DELETE CASCADE
ON UPDATE CASCADE,
data_col VARCHAR(20) NOT NULL
)
;
INSERT INTO Questions VALUES (1)
;
INSERT INTO Questions VALUES (2)
;
INSERT INTO Questions VALUES (3)
;
INSERT INTO Answers VALUES (1, 'Don''t know')
;
INSERT INTO Answers VALUES (3, 'Can''t say')
;
SELECT Questions.key_col,
IIF(Answers.data_col IS NULL, 'N', 'Y') AS has_been_answered,
Answers.data_col
FROM Questions LEFT JOIN Answers
ON Questions.key_col = Answers.key_col
;

BruceM wrote:
I just want to say that for me at least it is bewildering the way you
present a suggested table design. I wouldn't know where to run that code

1. If you are using AccessXP or Access2003:
With the .mdb open in ANSI SQL query mode
(http://office.microsoft.com/en-us/as...704831033.aspx),
open a Query object in SQL view and execute each semi-colon-separated
statement.

2. If you are using Access2000:
With the .mdb open, navigate to the VBE (Tools, Macro, Visual Basic
Editor) and in the Immediate Window (View, Immediate Window) run this
VBA:

CurrentProject.Connection.Execute "sql_here"

replacing sql_here, once for each semi-colon-separated statement

3. If you are using a version prior to Access2000 then it may be time
for an upgrade g.

why I would prefer it over design view

Writing such SQL DDL (data declaration language) is how I create
database schemas. Don't knock it until you've tried it: you may find,
like me, you never go back to using GUI tools to write your code for
you ;-)

For me (or anyone) to converted SQL DDL into the description of how to
do the same with Access's GUI tools (navigating menu items, panes,
dialog controls, mouse clicks, button presses, etc) would take
considerably more time. I know because I tried it once:

http://groups.google.com/group/micro...153523bd678cf9

Also it surely must be harder for the reader to implement such
descriptions, which anyway can be ambiguous. On the other hand, code is
prescriptive: executing a code script should yield the same results for
everyone.

In other database groups (comp.databases.*,
microsoft.public.sqlserver.*, etc) to NOT post schema as DDL and test
data as INSERT INTO statements is bad netiquette. I for one (and it may
well only be me g) think the people who read the
Microsoft.public.access.* groups deserve the same high standards.

Thanks for the reply. I now understand how I could act upon a DDL-language
suggestion that I implement a particular structure. For myself I find the
GUI tools for table design to be quick and easy, although I will agree that
it can be tedious to convey a suggestion. As for the other database groups,
I guess I'll stay away from them, as I don't have time to learn a new
language and still do the rest of my job. Or is there some equivalent of a
DDL view, the way there is a SQL view for queries?

wrote in message
oups.com...

BruceM wrote:
I just want to say that for me at least it is bewildering the way you
present a suggested table design. I wouldn't know where to run that code

1. If you are using AccessXP or Access2003:
With the .mdb open in ANSI SQL query mode
(http://office.microsoft.com/en-us/as...704831033.aspx),
open a Query object in SQL view and execute each semi-colon-separated
statement.

2. If you are using Access2000:
With the .mdb open, navigate to the VBE (Tools, Macro, Visual Basic
Editor) and in the Immediate Window (View, Immediate Window) run this
VBA:

CurrentProject.Connection.Execute "sql_here"

replacing sql_here, once for each semi-colon-separated statement

3. If you are using a version prior to Access2000 then it may be time
for an upgrade g.

why I would prefer it over design view

Writing such SQL DDL (data declaration language) is how I create
database schemas. Don't knock it until you've tried it: you may find,
like me, you never go back to using GUI tools to write your code for
you ;-)

For me (or anyone) to converted SQL DDL into the description of how to
do the same with Access's GUI tools (navigating menu items, panes,
dialog controls, mouse clicks, button presses, etc) would take
considerably more time. I know because I tried it once:

http://groups.google.com/group/micro...153523bd678cf9

Also it surely must be harder for the reader to implement such
descriptions, which anyway can be ambiguous. On the other hand, code is
prescriptive: executing a code script should yield the same results for
everyone.

In other database groups (comp.databases.*,
microsoft.public.sqlserver.*, etc) to NOT post schema as DDL and test
data as INSERT INTO statements is bad netiquette. I for one (and it may
well only be me g) think the people who read the
Microsoft.public.access.* groups deserve the same high standards.

BruceM wrote:
As for the other database groups,
I guess I'll stay away from them, as I don't have time to learn a new
language and still do the rest of my job.

I know what you mean: who wants to learn the in's and out's of four or
five SQL dialects? That's why I try to write SQL (DDL but also DML) as
close as possible to Standard SQL.