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!

Backup of Synchronised Database. 2

Status
Not open for further replies.

BruceJackson

Technical User
Apr 30, 2003
29
GB
What is the best way of backing up a Synchronised Database to enable recovery when the Master Copy becomes corrupted.
 
To me the BEST approach is to always create a backup copy of your design master after making any structure changes.

If your design master is not part of the circle that is involved with the sync process, I would make a backup copy of the primary replica AFTER all sync's have been performed.

You should perform backups of all databases on some regular schedule.

"Have a great day today and a better day tomorrow!
 
If I make a copy of the Design Master, it becomes a replica?
 
No, making a physical copy of a file does not make it a replica. You make replicas by the Tools | Replication | Make Replica command.

I have seen people use two different approaches:
1. Use their design master in the loop that gets synchronized.
2. Not use their design master in the loop.


"Have a great day today and a better day tomorrow!
 
I make a copy of the Design Master by right-click, copy and paste. The copy is named as type "Replica" and I am prevented from making changes. Is copy and paste the correct method of making a "copy"?

Or are you saying that the copy of the design master can be restored when necessary to be the Design Master? How and if I do this, will the Replicas stil synch with the restored Design Master?

 
Yes, you are correct. Creating a copy of the Design Master actually sets the type to replica.

Yes, the "copy of Design Master" can be converted back to a Design Master by using the "Recover Design Master" menu command.

To me, the important thing is having something available that is fairly current! Since you can always recover the design master, try to keep the most up-to-date version!

Good Luck.

"Have a great day today and a better day tomorrow!
 
Need much more help please!

I have taken a recent copy of Master and pasted into it's original position on server, then changed it's namr to what the Master was originally called but...

Macros are working but not from forms.

When I click on a Macro on a form, I get:

"Invalid Data Format."

When I try to click an event button on a form I get:

"The expression ON Click you entered as the event property setting produced the following error: Error accessing file. Network connections may have been lost.

*The expression may result in the name of a macro, the name of a user-defined function, or[Event Procedure].
*There may have been an error evaluating the function,event or macro."
 
Ahhh, I don't think you can fool Mother Microsoft quite that that easily.
1. Have you LOST your original design master? If not, does it run correctly? If not, you need to debug what the problem is.
2. If yo LOST your original, then I suggest you take the MOST UP-TO-DATE replica and make it your design master. Does this work?

If you are receiving the dreaded "Error accessing file. Network connections may have been lost" then your code project has become corrupted (search Microsoft Knowledge base for more detailed info). The only option I know of is to go back to a good version and try and update whatever code you have changed. You can try importing, but you MUST READ the knowledge base article first to understand HOW/WHY the code is corrupted.

"Have a great day today and a better day tomorrow!
 
Hello Trevil

Do you see any problems with the way I have dealt with this?

1. Created new dbs with new Module 1.

2. Imported queries, forms, macros from latest good copy of Design Master.

3. In latest good copy of Design Master, used make table queries to create copies of all tables excluding synch-type fields. I would expect that these tables are now free of any synch-type relationship/code.

4. Then imported these tables to the new dbs and re-set primary keys, relationships, field properties and look-ups.

5. Used append queries to import recent data from corrupt design Master.

The database has now been working most of today with no problems with 3 users and seems to be absolutely fine.

I will convert to a synchronised version with replicas next week when our sales team come back into the office but I have taken a copy and tested it synchronised on my hard drive - seems ok.

One other point, we all use Access 2002, the datbase was originally created using Access 2002 as a 2000 file format - would it be better to convert it to 2002 file format before synchronising?

Any final hints or advise would be appreciated and many thanks for your help so far.

"Having a great day tomorrow but yeserday was hell!"


 
It sounds as if what you have done so far is great. If you have not lost data or functionality -- that's a GOOD thing!

Re the 2002/2000 format, I would just make sure that you synch with ALL of the 2000 formatted databases before you start converting to 2002.


Good Luck.


"Have a great day today and a better day tomorrow!
 
If you have multiple users why have you chosen to use the replication function over splitting the database?

My personal rule always is: Multi-user = Split Database
Its so much less hassle and corruption is much more difficult.

~Phil4tektips~
Grant us peace in our days work!
 
We are based in Derbyshire where the Design Master is held on a server and we have users from another site in Scotland and 3 "out-on-the-road" laptop users.

A split database is hopelessly slow over the network.

The database is a Project Management database similar in functionality to Sales Logix so is used daily by all users and up-to-date project contact history is extremely important.

 
I thought that might be the case. You are right to be replicating then, those back-ups prove vital though!

Good luck.

~Phil4tektips~
Grant us peace in our days work!
 
Hi Phil4tektips,

I have several other databases, some with links to our Sage Line200 Database. Eg:

Production Scheduling linked to Sage.
Data prep for bespoke product import to Sage.
Reporting databases linked to Sage.
etc

By splitting the database, I assume you mean having the tables in a seperate database with queries, forms, macros etc in a Front End datbase.

In a case like this, do you have only one copy of the front end?
And how does this make corruption less dificult?

I have tried this method but tends to run more slowly.

Any guidance gratefully recieved.
 
I'm no expert in Access, but I have recently set up a multi user database which is working well. The environment is that all my users are sat at desktop pc's at different locations in the country.

I split the database to allow multiple user's to access it and update / add data at the same time. You're right about the split, all functionality goes in the Front-End (FE) and all the tables go in the Back-End (BE)

The BE resides in a shared drive, and I distribute the FE via a Batch file. The user clicks on the batch file icon on their desktop, this copies the FE to their hardrive and opens the FE from their hardrive.

All the links to the data on teh shared drive remain, and they can log in whenever they want.

To my understanding replicating was designed for data.

Any changes one user makes another will be able to see straight away on their screen, therefore there is no need to synchronise data, since they all share the same. Corruption therefore is made much less likely.

There are lots of threads on here about the pros and cons of splitting, and threads about Splitting Vs Replicating including a thread that I started on that topic.

~Phil4tektips~
Grant us peace in our days work!
 
Is it easy to explain how to:

"... distribute the FE via a Batch file. The user clicks on the batch file icon on their desktop, this copies the FE to their hardrive and opens the FE from their hardrive."

I am assuming that the user runs the batch file every time they access the database and they always get an up-to-date FE?

This could well be a better alternative for us if we have any more hassle with the Replicated version. The only thing we would lose is the ability for laptop users to access the system from a Little Chef or Burger King or McDonalds...
 
Yes thats correct. It means that making an update to the FE is relatively painless.

I keep a copy of the FE for myself. When I want to make an update I make the changes in the copy. When I am happy that the changes are working correctly, I replace live database with this new one. The live database is copied by the batch file everytime the user clicks on teh batch file routine. They have an updated version without ever really being aware an update has occured.

The code below writes a copy of the FE to the users Hardrive, in a folder called 'FEDB' (Front End DataBase)! lol.

Code (Copy and paste into Notepad):

echo off
c:
cd\
if not exist H:\Msoffice\Personal\FEDB\ mkdir H:\Msoffice\Personal\FEDB\

cd FEDB

REM Copy MyFE.mdb to the users H:\Drive
copy "J:\xxx\xxx\xxxx\MyFE.mdb" "H:\Msoffice\Personal\FEDB\MyFE.mdb"

REM Now start up the Database. Make sure the paths are correct:
"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE" "H:\Msoffice\Personal\FEDB\MyFE.mdb"

exit

Save the notepad file and change the pathnames and file name (MyFE.mdb) to your relevant ones. Rename the file extension from *.txt to *.bat which is a batch file. You should see your icon for this file change from a text icon to a window with a cog in it.

~Phil4tektips~
Grant us peace in our days work!
 
Replace all "Live database" phrases with "live FE" !! It might make more sense.

~Phil4tektips~
Grant us peace in our days work!
 
All of this information should certainly help lots of people with making a decision on replication versus FE/BE, but I would like to clarify one thing. Re "...replicating was designed for data", it actually was designed to manage ALL objects found in a database.

For people that have full time connectivity to a server, the FE/BE approach is *probably* the best approach as it removes the hassle of performing syncs. However, for the people that have no connectivity and travel around entering lots of data, replication *probably* is their best bet.

"Have a great day today and a better day tomorrow!
 
Re: "To my understanding replicating was designed for data"

Who was it who said you need to understand to be understood?

My apologies, my information came from previous posts.

The point Trevil has made though is right, your 'environment' will quite often determine your means of deployment.

~Phil4tektips~
Grant us peace in our days work!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top