Adding a Field to a Form

[Guest]

I created a table, then a form. Then I added an employee ID field to my
table, but now it isn't in my form. How do I update the form without
recreating it with a wizard? I am using ACCESS 2003.

 

[Guest]

Add a new textbox on your form and set his RecordSource to the employee ID
table field (Since you added Employee ID to your table, it should be listed
in the RecourdSource dropdown if your form is bound to your table.) If your
form is bound to a query, you have to add the Employee ID to your query to be
able to add it to your form.

Yanick

 

[Douglas J Steele]

Is the form based on the table, or on a query? If it's based on a query,
make sure that the query includes the new field.

Once the new field is included in the form's recordsource, simply add a new
textbox to your form, with the new field as its control source.

 

[Guest]

1st you really look at creating a query from the table and then creating form
from the query. (It's not a good idea to work straight from the table and
with a query you can run many other functions that are not possible in a
table).

Either way open your form in design view and click the view menu. From the
dropdown list select View Fields". Drag the new field into the form.

Hope this helps

 

[SusanV]

Wayne,

Why do you say to create a query - that you shouldn't have the form based on
a table? Queries are accessible to users, who sometimes like to play with
things they shouldn't - even in an MDE. With a split app, the linked tables
can't be modified as to design,. but queries can be. Therefore, myself, if
I'm basing a form on a single table, I always use the table. And unless it's
a fairly complex query, I code that into the form, rather than create a
stored query. (I have a few "problem child" users who can't leave things
alone <g>)

Not bustin' ya, just curious why you feel this way.

SusanV

 

[Douglas J Steele]

I always use queries so that I can control the order of the records on the
form, so that I can include calculated fields and so that I can pull in
information from other tables.

 

[SusanV]

How do you keep using from futzing with them?

I always use queries so that I can control the order of the records on the
form, so that I can include calculated fields and so that I can pull in
information from other tables.

 

[SusanV]

Keep *users* from...

Darn speel-chucker!

How do you keep using from futzing with them?

 

[Guest]

Hi Susan

In my opinion only (I may be wrong – like I was with England and Sweden last
night) but I was always told that tables are for storing data, queries are
use to combine and manipulate stored data and forms are used to view, correct
and function.

Using a form based on a query – taking that most queries are based on more
than 1 table will (sort of) ensure that the query will take care of any
Referential integrity problems that inexperienced users may come across if
working directly with a form based on multiple tables

One of the d bases I work with takes over 38,000 inputs per month (payments
and receipting) the use of too many functions on a form (which could be
better done in a base query) will slow the form down and with such a large
number of inputs per day the speed could be too slow to actually function.

As I said I may be wrong (I am about most things) but there are many reason
NOT to base a form on a table and hardy any TO.

The need to “see†the results of functions and “work†with them is what the
vast majority of d bases are used for
How many apples have I left on the shelf?
Who is working in the office next Wednesday?
Ect
These are all functions which are best undertaken in a query if possible
(sometimes it’s not) and then either display on screen, e mailed, printed. Of
course virtually any of these “could†be done on the form but that is not the
reason for using a form.

Don’t worry I fully expect many people to tell me I’m wrong. If I am,
please tell me as really do appreciate any help and advice.

 

[SusanV]

Thanks for replying Wayne,

Your arguments make sense, especially with calculated queries. I just wish
my users wouldn't mess with them. In particular, I have 2 users who know how
to make queries, which is fine - but they tend to be lazy and simply modify
existing ones - breaking all sorts of forms and reports etc. They drive me
batty! So for this particular group - the engineering department (go
figure!) - I hard-code almost everything, split and distribute an MDE for
the frontend. For another group, I can give them carte blanche and they
won't break a thing. I know I *could* use Access Security, but management
has decided that the engineers have enough passwords to deal with so that's
not an option (?!?) <sigh>

Oh and you wrote:
<q>
As I said I may be wrong (I am about most things)
</q>

I seriously doubt this is true!

;-)

SusanV

 

[Guest]

A slap round the head with a wet fish "may" stop them messing about with stuff.

I have split FE / BE most of our d bases and given most of the users varying
rights and this tends to stop "most" messing about. But, to put it bluntly
there is not a lot you can do when someone want to "have a look and see how
it works".

 

[SusanV]

Exactly! And boy am I tempted about the fish!!

A slap round the head with a wet fish "may" stop them messing about with
stuff.

I have split FE / BE most of our d bases and given most of the users
varying
rights and this tends to stop "most" messing about. But, to put it
bluntly
there is not a lot you can do when someone want to "have a look and see
how
it works".

 

[Pieter Wijnen]

by implementing user level security....

Pieter

Keep *users* from...

Darn speel-chucker!

 

[Pieter Wijnen]

by implementing user level security....

Pieter

Keep *users* from...

Darn speel-chucker!

--

 

[Pieter Wijnen]

You only need password for the superuser (owner)
all others can have a shortcut with /UID<UserName>
Or use the Admin Account with no password... (Still have to use
/WrkGrp<SystemDb> or modify registry)
In the latter case you would need a shortcut with /UID & optionally /PWD

HTH

Pieter

Exactly! And boy am I tempted about the fish!!

--

 

[Douglas J. Steele]

I don't care. If they break it, it's their fault <g>

--
Doug Steele, Microsoft Access MVP

(no private e-mails, please)

How do you keep using from futzing with them?

 

[SusanV]

Understood but not an option in this instance.

"Pieter Wijnen"

 

[SusanV]

Perhaps... Thanks for the suggestion!

"Pieter Wijnen"

 

[SusanV]

LOL!

I don't care. If they break it, it's their fault <g>

 

[Rick Brandt]

Perhaps... Thanks for the suggestion!

"Pieter Wijnen"

The query need not be a "saved query". It can be a SQL Statement entered into
the RecordSource property of the form. If you give users an MDE (so they can't
futz with your forms) then they won't have access to the query either.