sending and receiving tables with relationships

[prairiewind via AccessMonster.com]

I have a database with three linked tables (parent table, a child and a
"grandchild" table). There are 8 field reps in the company I work for. Each
of the parent tables cooresponds with the data pertaining to each rep. What
I'm wanting to do it to somehow separate the data so I can send each rep just
their table and corresponding children tables, they update the data and send
it back to me. Is there a way to do this? I have found a way to do it with
all the data in one table, but the forms to enter data end up being cluttered,
hard to navigate and confusing.

 

[Arvin Meyer [MVP]]

If you can identify each rep's data, it is simple to write a query to
separate it and use that query as the source of a Make-Table query. Separate
the data into separate back ends with the same front-end sent to each rep.
You can also use Access replication to distribute a replica to each rep.
Your database must be split to do that or you will invariably wind up with a
corrupt database.

 

[John W. Vinson]

I have a database with three linked tables (parent table, a child and a
"grandchild" table). There are 8 field reps in the company I work for. Each
of the parent tables cooresponds with the data pertaining to each rep. What
I'm wanting to do it to somehow separate the data so I can send each rep just
their table and corresponding children tables, they update the data and send
it back to me. Is there a way to do this? I have found a way to do it with
all the data in one table, but the forms to enter data end up being cluttered,
hard to navigate and confusing.

Well... then fix the forms. The one table is by far the best design. You
cannot extract a table from a database and send it separately!

It should be very easy to have a Form (based on the one master table) filtered
by the rep's ID to show only her data. The Subforms would link only to those
records. The rep's ID could be entered when they open Access, and they'd not
even need to see any extra controls at all!

John W. Vinson [MVP]

 

[David W. Fenton]

If you can identify each rep's data, it is simple to write a query
to separate it and use that query as the source of a Make-Table
query. Separate the data into separate back ends with the same
front-end sent to each rep. You can also use Access replication to
distribute a replica to each rep. Your database must be split to
do that or you will invariably wind up with a corrupt database

You can't exchange replicas once you've started editing the replica
in place, however. That is, once you've distributed a replica to its
editing location, it has to stay there, and synchs have to happen in
place with other replicas. You cannot copy or email replicas arouhd
once you've started entering data in them.

 

[Arvin Meyer [MVP]]

You can't exchange replicas once you've started editing the replica
in place, however. That is, once you've distributed a replica to its
editing location, it has to stay there, and synchs have to happen in
place with other replicas. You cannot copy or email replicas arouhd
once you've started entering data in them.

That's true. I didn't mean to give the impression that replicas could be
emailed around. The replica, or a partial replica must be sync'd with the
master as often as the data refreshing is required.

 

[David W. Fenton]

That's true. I didn't mean to give the impression that replicas
could be emailed around. The replica, or a partial replica must be
sync'd with the master as often as the data refreshing is
required.

And just to be repetitive, it must be synched in place, where it has
been edited. You can't copy it to some other location for synching.

 

[David W. Fenton]

I didn't mean to give the impression that replicas could be
emailed around.

And, oh, I forgot -- an explanation of *why* replicas have to be
synched in place is found here (no line wrap, no spaces, all on one
line):

http://groups.google.com/group/comp.databases.ms-access/msg/9f5a84194
fa6c653