Welcome to SPN

Register and Join the most happening forum of Sikh community & intellectuals from around the world.

Sign Up Now!

Adding a Field to a Form

Discussion in 'Information Technology' started by ktie2332, Jul 28, 2006.

Tags:
  1. ktie2332

    ktie2332
    Expand Collapse
    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.
    --
    Katie
     
  2. Loading...


  3. Yanick

    Yanick
    Expand Collapse
    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

    "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
     
  4. Wayne-I-M

    Wayne-I-M
    Expand Collapse
    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

    --
    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
     
  5. Douglas J Steele

    Douglas J Steele
    Expand Collapse
    Guest

    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" <ktie2332@discussions.microsoft.com> wrote in message
    news:ACF7DDB2-5834-4EE2-82AF-39F9F3A14752@microsoft.com...
    > 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
     
  6. SusanV

    SusanV
    Expand Collapse
    Guest

    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" <WayneIM@discussions.microsoft.com> wrote in message
    news:1462F13B-13B2-4E6D-9836-D58544786294@microsoft.com...
    > 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
     
  7. Douglas J Steele

    Douglas J Steele
    Expand Collapse
    Guest

    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" <svanallen@nospam-mvps.org> wrote in message
    news:%23YaE9NTlGHA.3816@TK2MSFTNGP02.phx.gbl...
    > 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" <WayneIM@discussions.microsoft.com> wrote in message
    > news:1462F13B-13B2-4E6D-9836-D58544786294@microsoft.com...
    > > 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

    >
    >
     
  8. SusanV

    SusanV
    Expand Collapse
    Guest

    How do you keep using from futzing with them?

    "Douglas J Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
    news:eZY8vSTlGHA.1344@TK2MSFTNGP03.phx.gbl...
    >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" <svanallen@nospam-mvps.org> wrote in message
    > news:%23YaE9NTlGHA.3816@TK2MSFTNGP02.phx.gbl...
    >> 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" <WayneIM@discussions.microsoft.com> wrote in message
    >> news:1462F13B-13B2-4E6D-9836-D58544786294@microsoft.com...
    >> > 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

    >>
    >>

    >
    >
     
  9. SusanV

    SusanV
    Expand Collapse
    Guest

    Keep *users* from...

    Darn speel-chucker!

    "SusanV" <svanallen@nospam-mvps.org> wrote in message
    news:euavtZTlGHA.1208@TK2MSFTNGP02.phx.gbl...
    > How do you keep using from futzing with them?
    >
    > "Douglas J Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
    > news:eZY8vSTlGHA.1344@TK2MSFTNGP03.phx.gbl...
    >>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" <svanallen@nospam-mvps.org> wrote in message
    >> news:%23YaE9NTlGHA.3816@TK2MSFTNGP02.phx.gbl...
    >>> 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" <WayneIM@discussions.microsoft.com> wrote in message
    >>> news:1462F13B-13B2-4E6D-9836-D58544786294@microsoft.com...
    >>> > 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
    >>>
    >>>

    >>
    >>

    >
    >
     
  10. Wayne-I-M

    Wayne-I-M
    Expand Collapse
    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.

    --
    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" <WayneIM@discussions.microsoft.com> wrote in message
    > news:1462F13B-13B2-4E6D-9836-D58544786294@microsoft.com...
    > > 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

    >
    >
    >
     
  11. SusanV

    SusanV
    Expand Collapse
    Guest

    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" <WayneIM@discussions.microsoft.com> wrote in message
    news:AA1C908A-7DF8-4B0E-9F16-38776CF54D8B@microsoft.com...
    > 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" <WayneIM@discussions.microsoft.com> wrote in message
    >> news:1462F13B-13B2-4E6D-9836-D58544786294@microsoft.com...
    >> > 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

    >>
    >>
    >>
     
  12. Wayne-I-M

    Wayne-I-M
    Expand Collapse
    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".


    --
    Wayne
    Manchester, England.



    "SusanV" wrote:

    > 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" <WayneIM@discussions.microsoft.com> wrote in message
    > news:AA1C908A-7DF8-4B0E-9F16-38776CF54D8B@microsoft.com...
    > > 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" <WayneIM@discussions.microsoft.com> wrote in message
    > >> news:1462F13B-13B2-4E6D-9836-D58544786294@microsoft.com...
    > >> > 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
    > >>
    > >>
    > >>

    >
    >
    >
     
  13. SusanV

    SusanV
    Expand Collapse
    Guest

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

    "Wayne-I-M" <WayneIM@discussions.microsoft.com> wrote in message
    news:7EB65C65-3710-408C-811E-0FD25E48183A@microsoft.com...
    >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".
    >
    >
    > --
    > Wayne
    > Manchester, England.
    >
    >
    >
    > "SusanV" wrote:
    >
    >> 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" <WayneIM@discussions.microsoft.com> wrote in message
    >> news:AA1C908A-7DF8-4B0E-9F16-38776CF54D8B@microsoft.com...
    >> > 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" <WayneIM@discussions.microsoft.com> wrote in message
    >> >> news:1462F13B-13B2-4E6D-9836-D58544786294@microsoft.com...
    >> >> > 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
    >> >>
    >> >>
    >> >>

    >>
    >>
    >>
     
  14. Pieter Wijnen

    Pieter Wijnen
    Expand Collapse
    Guest

    by implementing user level security....

    Pieter

    "SusanV" <svanallen@nospam-mvps.org> wrote in message
    news:%2341abbTlGHA.4172@TK2MSFTNGP04.phx.gbl...
    > Keep *users* from...
    >
    > Darn speel-chucker!
    >
    > "SusanV" <svanallen@nospam-mvps.org> wrote in message
    > news:euavtZTlGHA.1208@TK2MSFTNGP02.phx.gbl...
    >> How do you keep using from futzing with them?
    >>
    >> "Douglas J Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
    >> news:eZY8vSTlGHA.1344@TK2MSFTNGP03.phx.gbl...
    >>>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" <svanallen@nospam-mvps.org> wrote in message
    >>> news:%23YaE9NTlGHA.3816@TK2MSFTNGP02.phx.gbl...
    >>>> 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" <WayneIM@discussions.microsoft.com> wrote in message
    >>>> news:1462F13B-13B2-4E6D-9836-D58544786294@microsoft.com...
    >>>> > 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
    >>>>
    >>>>
    >>>
    >>>

    >>
    >>

    >
    >
     
  15. Pieter Wijnen

    Pieter Wijnen
    Expand Collapse
    Guest

    by implementing user level security....

    Pieter

    "SusanV" <svanallen@nospam-mvps.org> wrote in message
    news:%2341abbTlGHA.4172@TK2MSFTNGP04.phx.gbl...
    > Keep *users* from...
    >
    > Darn speel-chucker!
    >
    > "SusanV" <svanallen@nospam-mvps.org> wrote in message
    > news:euavtZTlGHA.1208@TK2MSFTNGP02.phx.gbl...
    >> How do you keep using from futzing with them?
    >>
    >> "Douglas J Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
    >> news:eZY8vSTlGHA.1344@TK2MSFTNGP03.phx.gbl...
    >>>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" <svanallen@nospam-mvps.org> wrote in message
    >>> news:%23YaE9NTlGHA.3816@TK2MSFTNGP02.phx.gbl...
    >>>> 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" <WayneIM@discussions.microsoft.com> wrote in message
    >>>> news:1462F13B-13B2-4E6D-9836-D58544786294@microsoft.com...
    >>>> > 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 am using the free version of SPAMfighter for private users.
    It has removed 4026 spam emails to date.
    Paying users do not have this message in their emails.
    Get the free SPAMfighter here: http://www.spamfighter.com/len
     
  16. Pieter Wijnen

    Pieter Wijnen
    Expand Collapse
    Guest

    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

    "SusanV" <svanallen@nospam-mvps.org> wrote in message
    news:uFO2K$TlGHA.3344@TK2MSFTNGP04.phx.gbl...
    > Exactly! And boy am I tempted about the fish!!
    >
    > "Wayne-I-M" <WayneIM@discussions.microsoft.com> wrote in message
    > news:7EB65C65-3710-408C-811E-0FD25E48183A@microsoft.com...
    >>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".
    >>
    >>
    >> --
    >> Wayne
    >> Manchester, England.
    >>
    >>
    >>
    >> "SusanV" wrote:
    >>
    >>> 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" <WayneIM@discussions.microsoft.com> wrote in message
    >>> news:AA1C908A-7DF8-4B0E-9F16-38776CF54D8B@microsoft.com...
    >>> > 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" <WayneIM@discussions.microsoft.com> wrote in message
    >>> >> news:1462F13B-13B2-4E6D-9836-D58544786294@microsoft.com...
    >>> >> > 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 am using the free version of SPAMfighter for private users.
    It has removed 4026 spam emails to date.
    Paying users do not have this message in their emails.
    Get the free SPAMfighter here: http://www.spamfighter.com/len
     
  17. Douglas J. Steele

    Douglas J. Steele
    Expand Collapse
    Guest

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

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


    "SusanV" <svanallen@nospam-mvps.org> wrote in message
    news:euavtZTlGHA.1208@TK2MSFTNGP02.phx.gbl...
    > How do you keep using from futzing with them?
    >
    > "Douglas J Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
    > news:eZY8vSTlGHA.1344@TK2MSFTNGP03.phx.gbl...
    >>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" <svanallen@nospam-mvps.org> wrote in message
    >> news:%23YaE9NTlGHA.3816@TK2MSFTNGP02.phx.gbl...
    >>> 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" <WayneIM@discussions.microsoft.com> wrote in message
    >>> news:1462F13B-13B2-4E6D-9836-D58544786294@microsoft.com...
    >>> > 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
    >>>
    >>>

    >>
    >>

    >
    >
     
  18. SusanV

    SusanV
    Expand Collapse
    Guest

    Understood but not an option in this instance.

    "Pieter Wijnen"
    <it.isi.llegal.to.send.unsollicited.mail.wijnen.nospam.please@online.replace.with.norway>
    wrote in message news:OaJM9xUlGHA.4708@TK2MSFTNGP04.phx.gbl...
    > by implementing user level security....
    >
    > Pieter
    >
    > "SusanV" <svanallen@nospam-mvps.org> wrote in message
    > news:%2341abbTlGHA.4172@TK2MSFTNGP04.phx.gbl...
    >> Keep *users* from...
    >>
    >> Darn speel-chucker!
    >>
    >> "SusanV" <svanallen@nospam-mvps.org> wrote in message
    >> news:euavtZTlGHA.1208@TK2MSFTNGP02.phx.gbl...
    >>> How do you keep using from futzing with them?
    >>>
    >>> "Douglas J Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
    >>> news:eZY8vSTlGHA.1344@TK2MSFTNGP03.phx.gbl...
    >>>>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" <svanallen@nospam-mvps.org> wrote in message
    >>>> news:%23YaE9NTlGHA.3816@TK2MSFTNGP02.phx.gbl...
    >>>>> 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" <WayneIM@discussions.microsoft.com> wrote in message
    >>>>> news:1462F13B-13B2-4E6D-9836-D58544786294@microsoft.com...
    >>>>> > 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 am using the free version of SPAMfighter for private users.
    > It has removed 4026 spam emails to date.
    > Paying users do not have this message in their emails.
    > Get the free SPAMfighter here: http://www.spamfighter.com/len
    >
    >
     
  19. SusanV

    SusanV
    Expand Collapse
    Guest

    Perhaps... Thanks for the suggestion!

    "Pieter Wijnen"
    <it.isi.llegal.to.send.unsollicited.mail.wijnen.nospam.please@online.replace.with.norway>
    wrote in message news:esCICyUlGHA.4716@TK2MSFTNGP04.phx.gbl...
    > 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
    >
    > "SusanV" <svanallen@nospam-mvps.org> wrote in message
    > news:uFO2K$TlGHA.3344@TK2MSFTNGP04.phx.gbl...
    >> Exactly! And boy am I tempted about the fish!!
    >>
    >> "Wayne-I-M" <WayneIM@discussions.microsoft.com> wrote in message
    >> news:7EB65C65-3710-408C-811E-0FD25E48183A@microsoft.com...
    >>>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".
    >>>
    >>>
    >>> --
    >>> Wayne
    >>> Manchester, England.
    >>>
    >>>
    >>>
    >>> "SusanV" wrote:
    >>>
    >>>> 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" <WayneIM@discussions.microsoft.com> wrote in message
    >>>> news:AA1C908A-7DF8-4B0E-9F16-38776CF54D8B@microsoft.com...
    >>>> > 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" <WayneIM@discussions.microsoft.com> wrote in message
    >>>> >> news:1462F13B-13B2-4E6D-9836-D58544786294@microsoft.com...
    >>>> >> > 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 am using the free version of SPAMfighter for private users.
    > It has removed 4026 spam emails to date.
    > Paying users do not have this message in their emails.
    > Get the free SPAMfighter here: http://www.spamfighter.com/len
    >
    >
     
  20. SusanV

    SusanV
    Expand Collapse
    Guest

    LOL!

    "Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
    news:epMJW5UlGHA.1340@TK2MSFTNGP02.phx.gbl...
    >I don't care. If they break it, it's their fault <g>
    >
    > --
    > Doug Steele, Microsoft Access MVP
    > http://I.Am/DougSteele
    > (no private e-mails, please)
    >
    >
    > "SusanV" <svanallen@nospam-mvps.org> wrote in message
    > news:euavtZTlGHA.1208@TK2MSFTNGP02.phx.gbl...
    >> How do you keep using from futzing with them?
    >>
    >> "Douglas J Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
    >> news:eZY8vSTlGHA.1344@TK2MSFTNGP03.phx.gbl...
    >>>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" <svanallen@nospam-mvps.org> wrote in message
    >>> news:%23YaE9NTlGHA.3816@TK2MSFTNGP02.phx.gbl...
    >>>> 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" <WayneIM@discussions.microsoft.com> wrote in message
    >>>> news:1462F13B-13B2-4E6D-9836-D58544786294@microsoft.com...
    >>>> > 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
    >>>>
    >>>>
    >>>
    >>>

    >>
    >>

    >
    >
     
  21. Rick Brandt

    Rick Brandt
    Expand Collapse
    Guest

    SusanV wrote:
    > 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.

    --
    Rick Brandt, Microsoft Access MVP
    Email (as appropriate) to...
    RBrandt at Hunter dot com
     

Share This Page