Duplicate MDB files

[Bob on Whidbey]

I want to use the same Access 2003 data base system on separate
desktops, at separate locations. There is no LAN. Of course both DB's
will have numerous additions and changes. Is there a "reasonable" way
to merge these two separate DBs into a single DB at a later date? This
seems pretty complicated, since new records in both DBs will have the
same IDNOs, yet be totally different data.

[DavidB]

On May 9, 2:44 pm, Bob on Whidbey <[e-mail]:

I want to use the same Access 2003 data base system on separate
desktops, at separate locations. There is no LAN. Of course both DB's
will have numerous additions and changes. Is there a "reasonable" way
to merge these two separate DBs into a single DB at a later date? This
seems pretty complicated, since new records in both DBs will have the
same IDNOs, yet be totally different data.

I assume you mean you want to merge tables since merging a couple of
databases simply involves import the table from each into a new
database. It is possible to do what you are asking (maybe) but you
havent come clsoe to giving enough info to get a proper answer not the
least of which is what is the objective you are attempting to satisfy
by merging the tables. Describe the total project and the
requirements then you should get a meaningful reply. Remember to
describe what you need in terms of the required objectives and not in
terms of how you think the objectives should be satisfied.

[King Ron]

On May 9, 1:44 pm, Bob on Whidbey <[e-mail]:

I want to use the same Access 2003 data base system on separate
desktops, at separate locations. There is no LAN. Of course both DB's
will have numerous additions and changes. Is there a "reasonable" way
to merge these two separate DBs into a single DB at a later date? This
seems pretty complicated, since new records in both DBs will have the
same IDNOs, yet be totally different data.

Look into the built in Replication features of Access. Last time I
used it in production, it was icky, fussy and bloated tables. It also
worked. One of those deals with the devil. basically it allows you to
have disconnected updates merged back into a master DB through any of
several different communications paths.

MS Online writeup at:

http://office.microsoft.com/en-us/ac...526841033.aspx

Bone chancy.

Ron, King of Chi

[Bob on Whidbey]

Look into the built in Replication features of Access. Last time I
used it in production, it was icky, fussy and bloated tables. It also
worked. One of those deals with the devil. basically it allows you to
have disconnected updates merged back into a master DB through any of
several different communications paths.

MS Online writeup at:

http://office.microsoft.com/en-us/ac...526841033.aspx

Bone chancy.

The Access system contains two MDB files with ALL tables included in
one MDB, linked to the other MDB. There are two offices that run
different events, using the same Access system. The offices are not
connected by a LAN and run independently. Contact info is added and
changes are made to each office's DB. Once a year there is a desire to
merge these DBs so that the both offices can STARTt, once again, with
separate but identical DBs.

I'm trying to get a handle on the big picture. It looks like
Replication is what's needed. Perhaps one office could use a Global
replica, while the other could be use a local replica. Once a year the
local office's DB could be synchronized with the global office's DB.
Then a local replica could be made from that synchronized global DB,
which would replace the copy at the local office.

Do I have the big picture about right?
Is it necessary to make replicas of both MDB files, or just the back-
end MDB file?
Would it be better to merge the two MDBs before starting this
replication process?

[Arno R]

"Bob on Whidbey" <bo**@whidbey.comschreef in bericht news:11**********************@o5g2000hsb.googlegro ups.com...

The Access system contains two MDB files with ALL tables included in
one MDB, linked to the other MDB. There are two offices that run
different events, using the same Access system. The offices are not
connected by a LAN and run independently. Contact info is added and
changes are made to each office's DB. Once a year there is a desire to
merge these DBs so that the both offices can STARTt, once again, with
separate but identical DBs.

I'm trying to get a handle on the big picture. It looks like
Replication is what's needed. Perhaps one office could use a Global
replica, while the other could be use a local replica. Once a year the
local office's DB could be synchronized with the global office's DB.
Then a local replica could be made from that synchronized global DB,
which would replace the copy at the local office.

Do I have the big picture about right?
Is it necessary to make replicas of both MDB files, or just the back-
end MDB file?
Would it be better to merge the two MDBs before starting this
replication process?

If I understand you correctly then I guess I would not use replication at all...
Replication is not at all that easy ... it has it's own pitfalls and difficulty's.
When it is *needed* to replicate, then use it, but in my idea you don't need that.

I get the idea that you only need to *add* the records from the other office once a year, right ??
This is since you are stating that "each office uses different events" and "run independently" ...
I don't see the data-structure here but ...
Is it possible to add 'OfficeID' to important tables, and/or to use a combined Primary key to make the record ID's different ??

Arno R

[Bob on Whidbey]

On May 10, 10:34 am, "Arno R" <[e-mail]:

If I understand you correctly then I guess I would not use replication at all...
Replication is not at all that easy ... it has it's own pitfalls and difficulty's.
When it is *needed* to replicate, then use it, but in my idea you don't need that.

I get the idea that you only need to *add* the records from the other office once a year, right ??
This is since you are stating that "each office uses different events" and "run independently" ...
I don't see the data-structure here but ...
Is it possible to add 'OfficeID' to important tables, and/or to use a combined Primary key to make the record ID's different ??

Each year, each office sends promotional material to the same people.
A once a year mass-mailing. They each update the contact DB and make
additions, very few deletions, and some correction to it during the
year. I'm hoping to have the changes made by office A incorporated
into the DB use by office B, and vice versa. The back-end MDB with all
the tables in only 5 MB. When I replicated it, it doubled in size to
10 MB.

What I believe would be necessary is a date/time stamp on each field
that is changed, as well as each record that is added. Another major
problem is the addition of the same person to DBs in both offices - a
very likely occurrence. I have no idea how replication handles that.

Perhaps what I'm hoping for doesn't exist. It seems darn complicated
to me.