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.
--
Katie

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

"ktie2332" wrote:

> 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.
> --
> Katie

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.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)


"ktie2332" <(E-Mail Removed)> wrote in message
news:ACF7DDB2-5834-4EE2-82AF-(E-Mail Removed)...
> 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.
> --
> Katie

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

--
Wayne
Manchester, England.



"ktie2332" wrote:

> 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.
> --
> Katie

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


"Wayne-I-M" <(E-Mail Removed)> wrote in message
news:1462F13B-13B2-4E6D-9836-(E-Mail Removed)...
> 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
>
> --
> Wayne
> Manchester, England.
>
>
>
> "ktie2332" wrote:
>
>> 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.
>> --
>> Katie

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.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)


"SusanV" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> 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
>
>
> "Wayne-I-M" <(E-Mail Removed)> wrote in message
> news:1462F13B-13B2-4E6D-9836-(E-Mail Removed)...
> > 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
> >
> > --
> > Wayne
> > Manchester, England.
> >
> >
> >
> > "ktie2332" wrote:
> >
> >> 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.
> >> --
> >> Katie
>
>

How do you keep using from futzing with them?

"Douglas J Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
news:(E-Mail Removed)...
>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.
>
> --
> Doug Steele, Microsoft Access MVP
> http://I.Am/DougSteele
> (no e-mails, please!)
>
>
> "SusanV" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>> 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
>>
>>
>> "Wayne-I-M" <(E-Mail Removed)> wrote in message
>> news:1462F13B-13B2-4E6D-9836-(E-Mail Removed)...
>> > 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
>> >
>> > --
>> > Wayne
>> > Manchester, England.
>> >
>> >
>> >
>> > "ktie2332" wrote:
>> >
>> >> 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.
>> >> --
>> >> Katie
>>
>>
>
>

Keep *users* from...

Darn speel-chucker!

"SusanV" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> How do you keep using from futzing with them?
>
> "Douglas J Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
> news:(E-Mail Removed)...
>>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.
>>
>> --
>> Doug Steele, Microsoft Access MVP
>> http://I.Am/DougSteele
>> (no e-mails, please!)
>>
>>
>> "SusanV" <(E-Mail Removed)> wrote in message
>> news:%(E-Mail Removed)...
>>> 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
>>>
>>>
>>> "Wayne-I-M" <(E-Mail Removed)> wrote in message
>>> news:1462F13B-13B2-4E6D-9836-(E-Mail Removed)...
>>> > 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
>>> >
>>> > --
>>> > Wayne
>>> > Manchester, England.
>>> >
>>> >
>>> >
>>> > "ktie2332" wrote:
>>> >
>>> >> 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.
>>> >> --
>>> >> Katie
>>>
>>>
>>
>>
>
>

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.

--
Wayne
Manchester, England.



"SusanV" wrote:

> 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
>
>
> "Wayne-I-M" <(E-Mail Removed)> wrote in message
> news:1462F13B-13B2-4E6D-9836-(E-Mail Removed)...
> > 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
> >
> > --
> > Wayne
> > Manchester, England.
> >
> >
> >
> > "ktie2332" wrote:
> >
> >> 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.
> >> --
> >> Katie
>
>
>

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

"Wayne-I-M" <(E-Mail Removed)> wrote in message
news:AA1C908A-7DF8-4B0E-9F16-(E-Mail Removed)...
> 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.
>
> --
> Wayne
> Manchester, England.
>
>
>
> "SusanV" wrote:
>
>> 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
>>
>>
>> "Wayne-I-M" <(E-Mail Removed)> wrote in message
>> news:1462F13B-13B2-4E6D-9836-(E-Mail Removed)...
>> > 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
>> >
>> > --
>> > Wayne
>> > Manchester, England.
>> >
>> >
>> >
>> > "ktie2332" wrote:
>> >
>> >> 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.
>> >> --
>> >> Katie
>>
>>
>>