Database replicas change of design master
I have a design master database seating on our company server. I have a replica database on laptop of our salesperson. Synchronization is done over VPN.
Inside company several users are connected to design master.
All this works ok.
Problem is if I want to make design changes on some forms or tables.
I want to copy design master on my hard disk make changes on the form.
After that I would for the short period of time I kick of users from design master on server to import changed forms back on server design master. Then put back users on.
But as sun as copy design master to my hard disk it become new replica database and I am not allowed to do any changes relating to design.
This is big problem for me as maintenance of the databases is very complicated.
I need to kick of all users then do changes which sometimes take long time.
Is there any way to go around this problem and still keep this database setup and configuration (design master and replicas).
Any sugestions.
Inside company several users are connected to design master.
All this works ok.
Problem is if I want to make design changes on some forms or tables.
I want to copy design master on my hard disk make changes on the form.
After that I would for the short period of time I kick of users from design master on server to import changed forms back on server design master. Then put back users on.
But as sun as copy design master to my hard disk it become new replica database and I am not allowed to do any changes relating to design.
This is big problem for me as maintenance of the databases is very complicated.
I need to kick of all users then do changes which sometimes take long time.
Is there any way to go around this problem and still keep this database setup and configuration (design master and replicas).
Any sugestions.
ASKER
LambertHeenan.
To give you short history of development conditions.
Original database was developed and set up as one of many company shared databases on company server folder for 5-10 company employees.
Access and processing speed was good. Regarding constant databases move as new servers were introduced we found that splitting database to front and back end will not bring much advantage and will make maintenance more demanding.
We did not want to constantly update (reconnecting broken -changed links).
We have kept most of databases as one file and just make new shortcuts on user machine from new locations.
Then company wanted to gave 2 outside salesmen access to database. Access to database would be over VPN. At that point I tested option for splitting database and trying to share data with salesman, however the seed was very slow and this option was not viable.
So at the end I come to replication.
I replicated database made design master and gave replicas to outside users.
As to users side they are happy and satisfied.
Everything looks good and smooth.
As my side I have problem with maintenance all the time.
As I understand you properly you suggests to copy design master e.g. A to my hard disk and then change it from replica to design master e.g. B do the changes on B .
Then kick of my users from A and import changes from B to A as exclusive user of A .
To give you short history of development conditions.
Original database was developed and set up as one of many company shared databases on company server folder for 5-10 company employees.
Access and processing speed was good. Regarding constant databases move as new servers were introduced we found that splitting database to front and back end will not bring much advantage and will make maintenance more demanding.
We did not want to constantly update (reconnecting broken -changed links).
We have kept most of databases as one file and just make new shortcuts on user machine from new locations.
Then company wanted to gave 2 outside salesmen access to database. Access to database would be over VPN. At that point I tested option for splitting database and trying to share data with salesman, however the seed was very slow and this option was not viable.
So at the end I come to replication.
I replicated database made design master and gave replicas to outside users.
As to users side they are happy and satisfied.
Everything looks good and smooth.
As my side I have problem with maintenance all the time.
As I understand you properly you suggests to copy design master e.g. A to my hard disk and then change it from replica to design master e.g. B do the changes on B .
Then kick of my users from A and import changes from B to A as exclusive user of A .
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for suggestions.
You also say "I want to copy design master on my hard disk make changes on the form." From this I conclude that your design master includes forms and code and queries and whatever. This is not a good idea. The reason I say this is that every time a change is made to the design of anything in the design master, access makes entries in a system table to which you have no edit permissions at all. This table grows and grows and your application can wind up being very large, just because of the contents of the system table.
IMHO the solution to this problem is to only ever replicate tables.
So what you need is a split database, where the data resides in the "Back End", and forms, code, queries etc. are in the "Front End" which is linked to the back-end tables.
Your observed that copying the design master from A to B turns it into a regular replica. This is correct. Whenever a design master is moved (or copied) from the location in which it was created to any other location it automatically reverts to being a plain ordinary replica. The way to get out of this bind it to copy a replica to some location and then open it up. On the Tools/Replication menu there is an option to 'Recover Design Master'. Select this option and the new copy you made will become the design master.
Now that you have a design master (only containing tables) you can leave it where it is, and you will only every use it to modify the design of tables. Such table changes would then be propagated to the working replicas via a one-way synchronization (from the master to the replica).