Form for multiple client use and transfer of responses to table

G

Guest

I wish to create a form for staff to use that contains questions about their
existing skills and then have Access transfer their reponses automatically to
a table. I want Access to open at the same blank form each time ready for
staff to use, without the need to create a new form for every use. I assume
staff would fill in the form, answer the questions on it and then click on
Submit or something like this - their responses would then be transferred to
a table and the form cleared of data, ready for the next user.
Can this be done in Access?
your help with this is much appreciated
Philbie
 
J

Jeff Boyce

Philbie

Out of the box, Access provides ways to do this... (by the way, you posted
to a "TablesDBDesign" newsgroup, which focuses on tables, not forms)

First create your table(s) -- have you normalized your data?

Then create a query based on your table(s).

Now create a form based on the query. Set the Data Add property of the form
to Yes.
Add a command button that the user would press to <Save> the data (although
this is redundant - Access saves when the form is closed or the record is
left).

Each time the (only one) form is opened, it opens ready to accept (new)
data.

Regards

Jeff Boyce
Microsoft Office/Access MVP
 
J

Jamie Collins

by the way, you posted
to a "TablesDBDesign" newsgroup, which focuses on tables, not forms

FWIW when accessed via Office Online on Microsoft's website, this
group is captioned 'Access Database design'. See
http://www.microsoft.com/office/com...ft.public.access.tablesdbdesign&lang=en&cr=US

If you are proposing that Forms-related discussion is off-topic in
this group then I'll second you <g> but I fear the vagueness of the
terms 'Access' and 'database' respectively does not IMO make this
position intuitive or viable :(

It's a sad (IMO) fact that most people still think that relying on
front end forms to maintain data integrity, rather than constraints in
the DBMS, is good practice but it's undeniably a fact :(

Jamie.

--
 
J

Jeff Boyce

Jamie

The original poster may not realize that this is a continuing discussion
topic in the 'groups...

And you and I have, I believe, agreed to disagree on this point. While
adding CONSTRAINTS into data definition may be more elegant, I suspect it is
considerably less accessible to normal, every day use of Access. It is in
those circumstances that I'm proposing to embed business rules.

Regards

Jeff Boyce
Microsoft Office/Access MVP
 
J

Jamie Collins

The original poster may not realize that this is a continuing discussion
topic in the 'groups...

And you and I have, I believe, agreed to disagree on this point.

Indeed we had...
While
adding CONSTRAINTS into data definition may be more elegant, I suspect it is
considerably less accessible to normal, every day use of Access.

....but if you think that I have been evangelising 'elegance' all this
time then you've sadly missed my point. In brief, relying on the front
end to maintain data integrity assumes many things: that users will
not attempt to access the data via another application (Excel is a
very popular platform for doing this, just look in the Excel groups);
that the front end code does not and will never try to write bad data
(i.e. the myth of bug-free code); etc. I guess I've seen too many
cases where these assumptions have not held true :(
It is in
those circumstances that I'm proposing to embed business rules.

And what I was trying to say is that no one (FWIW me included)
considers a reply such as yours to the OP to be OT in this group.

Jamie.

--
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top