Welcome to SPN

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

Sign Up Now!

Transfer data to another table

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

  1. troy

    troy
    Expand Collapse
    Guest

    I would like to transfer data from one table to another while filtering out
    redundant product id numbers. I want to use the target table for additional
    queries etc. Is there something I can put in my criteria under Product ID
    that would filter this before it moves?
     
  2. Loading...

    Similar Threads Forum Date
    Soul transfer to another body Questions and Answers May 10, 2014
    Sikh Guruship transfer Sikh Sikhi Sikhism Mar 13, 2010
    Transfer of Sikh "Guruship" Sikh Youth Mar 13, 2010
    Sikh News SC issues notices to Punjab govt on Tytler's plea for case transfer (New Kerala) Breaking News Sep 9, 2008
    Sikh News Nine IAS officers transferred in Punjab (Outlook India) Breaking News Aug 29, 2008

  3. Larry Daugherty

    Larry Daugherty
    Expand Collapse
    Guest

    If both source and destination tables are within the same database
    then you really don't want to copy data from one to another. Visit
    "Ten Commandments" on www.mvps.org/access to see some more of the
    rules for relational databases.

    If you queries seem to be getting too complex then you could save that
    first query that yields just the data you wanted (for the table you
    shouldn't write) as a named query in the database|queries window.
    Anything that would have used your new data can now call on your new,
    named query.

    HTH
    --
    -Larry-
    --

    "troy" <troy@discussions.microsoft.com> wrote in message
    news:B2F1B979-7DE9-40E5-9337-39C86D04193E@microsoft.com...
    > I would like to transfer data from one table to another while

    filtering out
    > redundant product id numbers. I want to use the target table for

    additional
    > queries etc. Is there something I can put in my criteria under

    Product ID
    > that would filter this before it moves?
     
  4. troy

    troy
    Expand Collapse
    Guest

    Sorry I dont understad anything you are trying to say. Anyway thanks for your
    suggestion but I already know about the 10 comandments. However I have a
    table that has multiple data such as 3 or for of the same product id's
    because of new versions. Why the other developer built it as un normal as you
    can get is beyond me. Right now I am trying to figure out a way to be able to
    take any of the data that has been updated and update it to the current
    version, nbr etc or whatever it may be tat they are updateing. With 2 keys in
    the same table it makes it impossible to figure out a way. Right now I am
    doing a filter query to locate only the last product number (which will
    elimite the redundancy) then I can work from there.

    "Larry Daugherty" wrote:

    > If both source and destination tables are within the same database
    > then you really don't want to copy data from one to another. Visit
    > "Ten Commandments" on www.mvps.org/access to see some more of the
    > rules for relational databases.
    >
    > If you queries seem to be getting too complex then you could save that
    > first query that yields just the data you wanted (for the table you
    > shouldn't write) as a named query in the database|queries window.
    > Anything that would have used your new data can now call on your new,
    > named query.
    >
    > HTH
    > --
    > -Larry-
    > --
    >
    > "troy" <troy@discussions.microsoft.com> wrote in message
    > news:B2F1B979-7DE9-40E5-9337-39C86D04193E@microsoft.com...
    > > I would like to transfer data from one table to another while

    > filtering out
    > > redundant product id numbers. I want to use the target table for

    > additional
    > > queries etc. Is there something I can put in my criteria under

    > Product ID
    > > that would filter this before it moves?

    >
    >
    >
     
  5. Larry Daugherty

    Larry Daugherty
    Expand Collapse
    Guest

    I really don't understand much of what you have written. Since you
    also write that you can't understand what I wrote earlier, you may be
    in over your head technically. I do hope you have a backup copy of
    your complete application before you started making changes. If not,
    you should make a backup copy now. before you make any more changes.

    You may need competent Access help. Maybe you can get someone in your
    local market. You can also try getting your problem solved online.
    If your data isn't confidential you can decode my address and send me
    your application in a zip file (my mail client will delete an MDB or
    MDE). I'll have a look at it free of charge. Please also indicate
    your time zone and contact info.

    HTH
    --
    -Larry-
    --

    "troy" <troy@discussions.microsoft.com> wrote in message
    news:DA0321E0-89DC-46C3-8D68-D2F20E5A3908@microsoft.com...
    > Sorry I dont understad anything you are trying to say. Anyway thanks

    for your
    > suggestion but I already know about the 10 comandments. However I

    have a
    > table that has multiple data such as 3 or for of the same product

    id's
    > because of new versions. Why the other developer built it as un

    normal as you
    > can get is beyond me. Right now I am trying to figure out a way to

    be able to
    > take any of the data that has been updated and update it to the

    current
    > version, nbr etc or whatever it may be tat they are updateing. With

    2 keys in
    > the same table it makes it impossible to figure out a way. Right now

    I am
    > doing a filter query to locate only the last product number (which

    will
    > elimite the redundancy) then I can work from there.
    >
    > "Larry Daugherty" wrote:
    >
    > > If both source and destination tables are within the same database
    > > then you really don't want to copy data from one to another.

    Visit
    > > "Ten Commandments" on www.mvps.org/access to see some more of the
    > > rules for relational databases.
    > >
    > > If you queries seem to be getting too complex then you could save

    that
    > > first query that yields just the data you wanted (for the table

    you
    > > shouldn't write) as a named query in the database|queries window.
    > > Anything that would have used your new data can now call on your

    new,
    > > named query.
    > >
    > > HTH
    > > --
    > > -Larry-
    > > --
    > >
    > > "troy" <troy@discussions.microsoft.com> wrote in message
    > > news:B2F1B979-7DE9-40E5-9337-39C86D04193E@microsoft.com...
    > > > I would like to transfer data from one table to another while

    > > filtering out
    > > > redundant product id numbers. I want to use the target table for

    > > additional
    > > > queries etc. Is there something I can put in my criteria under

    > > Product ID
    > > > that would filter this before it moves?

    > >
    > >
    > >
     
  6. troy

    troy
    Expand Collapse
    Guest

    OK thanks but I dont need the help any longer. I have been advised that you
    can not do what I was trying to do but if there is a will there is a way. I
    have been doing this for about 8 years and most is fixing others mess. This
    one tops the cake. WHY? Because they want it done their way and not the
    correct way. Way below my standards and it makes it tough to do a patch when
    you know it is not the correct way. Dont like it but they are the boss. s
    long as they understand what I am doing and the consenquences that will arise
    after may departure. May b one month or a year but it will happen! Thanks
    again

    "Larry Daugherty" wrote:

    > I really don't understand much of what you have written. Since you
    > also write that you can't understand what I wrote earlier, you may be
    > in over your head technically. I do hope you have a backup copy of
    > your complete application before you started making changes. If not,
    > you should make a backup copy now. before you make any more changes.
    >
    > You may need competent Access help. Maybe you can get someone in your
    > local market. You can also try getting your problem solved online.
    > If your data isn't confidential you can decode my address and send me
    > your application in a zip file (my mail client will delete an MDB or
    > MDE). I'll have a look at it free of charge. Please also indicate
    > your time zone and contact info.
    >
    > HTH
    > --
    > -Larry-
    > --
    >
    > "troy" <troy@discussions.microsoft.com> wrote in message
    > news:DA0321E0-89DC-46C3-8D68-D2F20E5A3908@microsoft.com...
    > > Sorry I dont understad anything you are trying to say. Anyway thanks

    > for your
    > > suggestion but I already know about the 10 comandments. However I

    > have a
    > > table that has multiple data such as 3 or for of the same product

    > id's
    > > because of new versions. Why the other developer built it as un

    > normal as you
    > > can get is beyond me. Right now I am trying to figure out a way to

    > be able to
    > > take any of the data that has been updated and update it to the

    > current
    > > version, nbr etc or whatever it may be tat they are updateing. With

    > 2 keys in
    > > the same table it makes it impossible to figure out a way. Right now

    > I am
    > > doing a filter query to locate only the last product number (which

    > will
    > > elimite the redundancy) then I can work from there.
    > >
    > > "Larry Daugherty" wrote:
    > >
    > > > If both source and destination tables are within the same database
    > > > then you really don't want to copy data from one to another.

    > Visit
    > > > "Ten Commandments" on www.mvps.org/access to see some more of the
    > > > rules for relational databases.
    > > >
    > > > If you queries seem to be getting too complex then you could save

    > that
    > > > first query that yields just the data you wanted (for the table

    > you
    > > > shouldn't write) as a named query in the database|queries window.
    > > > Anything that would have used your new data can now call on your

    > new,
    > > > named query.
    > > >
    > > > HTH
    > > > --
    > > > -Larry-
    > > > --
    > > >
    > > > "troy" <troy@discussions.microsoft.com> wrote in message
    > > > news:B2F1B979-7DE9-40E5-9337-39C86D04193E@microsoft.com...
    > > > > I would like to transfer data from one table to another while
    > > > filtering out
    > > > > redundant product id numbers. I want to use the target table for
    > > > additional
    > > > > queries etc. Is there something I can put in my criteria under
    > > > Product ID
    > > > > that would filter this before it moves?
    > > >
    > > >
    > > >

    >
    >
    >
     
  7. Larry Daugherty

    Larry Daugherty
    Expand Collapse
    Guest

    Would they get in and interfere with the operating room personnel who
    are replacing their hip joint? Same kind of thing in that their
    interference in the technical side of things will definitely have
    consequences.

    --
    -Larry-
    --

    "troy" <troy@discussions.microsoft.com> wrote in message
    news:2340B3B1-C1A4-4399-8D9B-A50472E783DE@microsoft.com...
    > OK thanks but I dont need the help any longer. I have been advised

    that you
    > can not do what I was trying to do but if there is a will there is a

    way. I
    > have been doing this for about 8 years and most is fixing others

    mess. This
    > one tops the cake. WHY? Because they want it done their way and not

    the
    > correct way. Way below my standards and it makes it tough to do a

    patch when
    > you know it is not the correct way. Dont like it but they are the

    boss. s
    > long as they understand what I am doing and the consenquences that

    will arise
    > after may departure. May b one month or a year but it will happen!

    Thanks
    > again
    >
    > "Larry Daugherty" wrote:
    >
    > > I really don't understand much of what you have written. Since

    you
    > > also write that you can't understand what I wrote earlier, you may

    be
    > > in over your head technically. I do hope you have a backup copy

    of
    > > your complete application before you started making changes. If

    not,
    > > you should make a backup copy now. before you make any more

    changes.
    > >
    > > You may need competent Access help. Maybe you can get someone in

    your
    > > local market. You can also try getting your problem solved

    online.
    > > If your data isn't confidential you can decode my address and send

    me
    > > your application in a zip file (my mail client will delete an MDB

    or
    > > MDE). I'll have a look at it free of charge. Please also

    indicate
    > > your time zone and contact info.
    > >
    > > HTH
    > > --
    > > -Larry-
    > > --
    > >
    > > "troy" <troy@discussions.microsoft.com> wrote in message
    > > news:DA0321E0-89DC-46C3-8D68-D2F20E5A3908@microsoft.com...
    > > > Sorry I dont understad anything you are trying to say. Anyway

    thanks
    > > for your
    > > > suggestion but I already know about the 10 comandments. However

    I
    > > have a
    > > > table that has multiple data such as 3 or for of the same

    product
    > > id's
    > > > because of new versions. Why the other developer built it as un

    > > normal as you
    > > > can get is beyond me. Right now I am trying to figure out a way

    to
    > > be able to
    > > > take any of the data that has been updated and update it to the

    > > current
    > > > version, nbr etc or whatever it may be tat they are updateing.

    With
    > > 2 keys in
    > > > the same table it makes it impossible to figure out a way. Right

    now
    > > I am
    > > > doing a filter query to locate only the last product number

    (which
    > > will
    > > > elimite the redundancy) then I can work from there.
    > > >
    > > > "Larry Daugherty" wrote:
    > > >
    > > > > If both source and destination tables are within the same

    database
    > > > > then you really don't want to copy data from one to another.

    > > Visit
    > > > > "Ten Commandments" on www.mvps.org/access to see some more of

    the
    > > > > rules for relational databases.
    > > > >
    > > > > If you queries seem to be getting too complex then you could

    save
    > > that
    > > > > first query that yields just the data you wanted (for the

    table
    > > you
    > > > > shouldn't write) as a named query in the database|queries

    window.
    > > > > Anything that would have used your new data can now call on

    your
    > > new,
    > > > > named query.
    > > > >
    > > > > HTH
    > > > > --
    > > > > -Larry-
    > > > > --
    > > > >
    > > > > "troy" <troy@discussions.microsoft.com> wrote in message
    > > > > news:B2F1B979-7DE9-40E5-9337-39C86D04193E@microsoft.com...
    > > > > > I would like to transfer data from one table to another

    while
    > > > > filtering out
    > > > > > redundant product id numbers. I want to use the target table

    for
    > > > > additional
    > > > > > queries etc. Is there something I can put in my criteria

    under
    > > > > Product ID
    > > > > > that would filter this before it moves?
    > > > >
    > > > >
    > > > >

    > >
    > >
    > >
     
  8. troy

    troy
    Expand Collapse
    Guest

    Yo got that right!

    "Larry Daugherty" wrote:

    > Would they get in and interfere with the operating room personnel who
    > are replacing their hip joint? Same kind of thing in that their
    > interference in the technical side of things will definitely have
    > consequences.
    >
    > --
    > -Larry-
    > --
    >
    > "troy" <troy@discussions.microsoft.com> wrote in message
    > news:2340B3B1-C1A4-4399-8D9B-A50472E783DE@microsoft.com...
    > > OK thanks but I dont need the help any longer. I have been advised

    > that you
    > > can not do what I was trying to do but if there is a will there is a

    > way. I
    > > have been doing this for about 8 years and most is fixing others

    > mess. This
    > > one tops the cake. WHY? Because they want it done their way and not

    > the
    > > correct way. Way below my standards and it makes it tough to do a

    > patch when
    > > you know it is not the correct way. Dont like it but they are the

    > boss. s
    > > long as they understand what I am doing and the consenquences that

    > will arise
    > > after may departure. May b one month or a year but it will happen!

    > Thanks
    > > again
    > >
    > > "Larry Daugherty" wrote:
    > >
    > > > I really don't understand much of what you have written. Since

    > you
    > > > also write that you can't understand what I wrote earlier, you may

    > be
    > > > in over your head technically. I do hope you have a backup copy

    > of
    > > > your complete application before you started making changes. If

    > not,
    > > > you should make a backup copy now. before you make any more

    > changes.
    > > >
    > > > You may need competent Access help. Maybe you can get someone in

    > your
    > > > local market. You can also try getting your problem solved

    > online.
    > > > If your data isn't confidential you can decode my address and send

    > me
    > > > your application in a zip file (my mail client will delete an MDB

    > or
    > > > MDE). I'll have a look at it free of charge. Please also

    > indicate
    > > > your time zone and contact info.
    > > >
    > > > HTH
    > > > --
    > > > -Larry-
    > > > --
    > > >
    > > > "troy" <troy@discussions.microsoft.com> wrote in message
    > > > news:DA0321E0-89DC-46C3-8D68-D2F20E5A3908@microsoft.com...
    > > > > Sorry I dont understad anything you are trying to say. Anyway

    > thanks
    > > > for your
    > > > > suggestion but I already know about the 10 comandments. However

    > I
    > > > have a
    > > > > table that has multiple data such as 3 or for of the same

    > product
    > > > id's
    > > > > because of new versions. Why the other developer built it as un
    > > > normal as you
    > > > > can get is beyond me. Right now I am trying to figure out a way

    > to
    > > > be able to
    > > > > take any of the data that has been updated and update it to the
    > > > current
    > > > > version, nbr etc or whatever it may be tat they are updateing.

    > With
    > > > 2 keys in
    > > > > the same table it makes it impossible to figure out a way. Right

    > now
    > > > I am
    > > > > doing a filter query to locate only the last product number

    > (which
    > > > will
    > > > > elimite the redundancy) then I can work from there.
    > > > >
    > > > > "Larry Daugherty" wrote:
    > > > >
    > > > > > If both source and destination tables are within the same

    > database
    > > > > > then you really don't want to copy data from one to another.
    > > > Visit
    > > > > > "Ten Commandments" on www.mvps.org/access to see some more of

    > the
    > > > > > rules for relational databases.
    > > > > >
    > > > > > If you queries seem to be getting too complex then you could

    > save
    > > > that
    > > > > > first query that yields just the data you wanted (for the

    > table
    > > > you
    > > > > > shouldn't write) as a named query in the database|queries

    > window.
    > > > > > Anything that would have used your new data can now call on

    > your
    > > > new,
    > > > > > named query.
    > > > > >
    > > > > > HTH
    > > > > > --
    > > > > > -Larry-
    > > > > > --
    > > > > >
    > > > > > "troy" <troy@discussions.microsoft.com> wrote in message
    > > > > > news:B2F1B979-7DE9-40E5-9337-39C86D04193E@microsoft.com...
    > > > > > > I would like to transfer data from one table to another

    > while
    > > > > > filtering out
    > > > > > > redundant product id numbers. I want to use the target table

    > for
    > > > > > additional
    > > > > > > queries etc. Is there something I can put in my criteria

    > under
    > > > > > Product ID
    > > > > > > that would filter this before it moves?
    > > > > >
    > > > > >
    > > > > >
    > > >
    > > >
    > > >

    >
    >
    >
     

Share This Page