I have a Sales Contact Dbase set up on my server (two tables, main & sub) Three sales reps (initially) have an exact copy on there laptops. As each of us updates our Db, we wish to import/export new information to each others db. Is this possible, if so could someone point me in general direction. In anticipation - THANKS FOR YOUR HELP!
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Two way remote update of Access Dbase
- Thread starter grendal
- Start date
mikehoot
Technical User
- Oct 18, 2001
- 97
Have a look in access help for "replication". This will convert a standard db into a "design master", where all updates to the design must be made, and will create a "replica" which can be automatically synchronised with the master. If you have ytour laptops on your network then this is made much easier.
One thing to at least be aware of is that any fields which are using incremental autonumber fields for the primary key will be changed to a "globally unique ID" GUID in order to avoid duplicate conflicts between replica sets. Existing records will retain their autonumbers, but new records will have a longer string of numbers.
Good luck :-9
One thing to at least be aware of is that any fields which are using incremental autonumber fields for the primary key will be changed to a "globally unique ID" GUID in order to avoid duplicate conflicts between replica sets. Existing records will retain their autonumbers, but new records will have a longer string of numbers.
Good luck :-9
- Thread starter
- #3
Replication is actually not as difficult as the documentations might make it sound.
Basically, the simple way to accomplish what you want to di with replication is:
-- create a design master database by enabling your existing database for replication.
-- you will use the design master as your main database at your "home base"
-- create three replicas and install one on each of the three salesperson's laptops.
-- when the salespeople need to update the design master with changes, and get changes made to design master and other replicas, just put them on the network and choose the "synchronize" replica choice from the replication menu. Then specify which replica you want to synchronize and push the button. Changes from the salesperson's replica will be uploaded, and changes made on the design master (which may have come from other replicas) will also be downloaded the the syncrhonizing replica.
I was a little intimidated at first by descriptions of replication. But when you actually do it you will probably find out it's not as difficult or mysterious as it seems.
If you can't bring the salespersons' laptops on to the network to synchronize, then you can also do it fairly easily (depending on size of database and whether or not you have broadband connections) by having them email their current database in, doing the syncrhonization at the home base, and emailing back the new syncrhonized replica.
There are also ways to set up synchronization automatically over the internet, without having to email the .mdb file in, but that is more difficult to configure. -- Herb
Basically, the simple way to accomplish what you want to di with replication is:
-- create a design master database by enabling your existing database for replication.
-- you will use the design master as your main database at your "home base"
-- create three replicas and install one on each of the three salesperson's laptops.
-- when the salespeople need to update the design master with changes, and get changes made to design master and other replicas, just put them on the network and choose the "synchronize" replica choice from the replication menu. Then specify which replica you want to synchronize and push the button. Changes from the salesperson's replica will be uploaded, and changes made on the design master (which may have come from other replicas) will also be downloaded the the syncrhonizing replica.
I was a little intimidated at first by descriptions of replication. But when you actually do it you will probably find out it's not as difficult or mysterious as it seems.
If you can't bring the salespersons' laptops on to the network to synchronize, then you can also do it fairly easily (depending on size of database and whether or not you have broadband connections) by having them email their current database in, doing the syncrhonization at the home base, and emailing back the new syncrhonized replica.
There are also ways to set up synchronization automatically over the internet, without having to email the .mdb file in, but that is more difficult to configure. -- Herb
I'm not a good person to ask. I've had experience only with one database that hasn't been a problem. But I do know that there are plenty of people who have reported problems with replication. I do think that a good number of reported problems are from people who aren't quite sure what they're doing. Others, though, are probably real, so it's something to be aware of. -- Herb
I use a replicated DB for 3 years and so far with no problem.However there are one thing I would like to nkow.
My DB is 20MB size.
From this DB I made a non replicated DB - 4MB
Then, from this one I made again a replicated DB an the size is just 10MB.
Why this change of size??
Garrido
My DB is 20MB size.
From this DB I made a non replicated DB - 4MB
Then, from this one I made again a replicated DB an the size is just 10MB.
Why this change of size??
Garrido
The inflated replicated database sounds like a problem with compacting. MSFT gives some information about compacting with replicated databases at this link:
Basically, it sounds like the most important thing to remember is to always compact a design master before synchronizing. Though there are also other comments about compacting the individual replicas.
Replicating the database adds some fields to the database, so it's guaranteed to make any database take up a bit more space. But the size difference in yours sounds like more than just the added fields, which makes me think that there are issues with compacting. -- Herb
Basically, it sounds like the most important thing to remember is to always compact a design master before synchronizing. Though there are also other comments about compacting the individual replicas.
Replicating the database adds some fields to the database, so it's guaranteed to make any database take up a bit more space. But the size difference in yours sounds like more than just the added fields, which makes me think that there are issues with compacting. -- Herb
Herb, thanks for interest.
I do compact twice my DB.
Ten minutes ago I made again what I told before.
1 -Compact twice the DB - 20996KB
2 -Made a regular DB (non replicated) - 6124KB
3 -From that one made again two replicas:The MASTER -10.885 KB and one replica 12686KB.
That's what I do not understand why the big differnce between two DB with same records,same forms...
garrido
I do compact twice my DB.
Ten minutes ago I made again what I told before.
1 -Compact twice the DB - 20996KB
2 -Made a regular DB (non replicated) - 6124KB
3 -From that one made again two replicas:The MASTER -10.885 KB and one replica 12686KB.
That's what I do not understand why the big differnce between two DB with same records,same forms...
garrido
mikehoot
Technical User
- Oct 18, 2001
- 97
Have a look at the help files for added tables and fields when using replication. These will differ between the replicas and the design master and could relate to your differing file sizes. As your non-replicated db is over 6000kb, I wouldn't be too concerned with having master and replicas of 10000 - 12000kb.
:-9
:-9
- Status
Similar threads
- Locked
- Question