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 Wanet Telecoms Ltd on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Splitting and backing up database. Want to make sure this is right.

Status
Not open for further replies.

amy3000

Technical User
Sep 25, 2000
59
US
I've developed a database that will be used by 3 people primarily. One will be doing data entry and two will be querying and running reports.

I plan to split the database and have all 3 users use the same front end. Is there a particular way the front end and back end should be backed up? I was just going to ask the data entry person to copy both fe and be to her hard drive or to a disc as needed after she's done entering new data.

It appears from playing with this a bit that to update or add tables, I need to make the change in the back end and then link to the table in the front end. Is this correct?

A final question. If the 2 who will be querying the data want to take it with them, say on a laptop, or just want to use it at the same time the data entry person needs to be in it, is there any problem just having them make a copy of the front end and back end to their hard drive?

I've looked at replicating but it seems more complicated and unecessary.

I did search on this but didn't find exaclty the info I was looking for. Thanks.
 
There is no standard method of doing backup, really. Most places do it by backing up the server, but there's nothing wrong with having your data entry person make copies, as long as (1) she doesn't ever open the backup copies, and (2) she doesn't restore them at an inappropriate time. That's a question of how trustworthy she is.

All tables that contain shared data that was entered by the users should be in the back end, and linked in the front end. (It's ok to keep some tables in the front end, if they're never updated and only used by your code.) But I'm not sure I got your question right. Were you talking about updating and adding tables as you make changes to the application? Or were you talking about the data entry user updating and adding records?

Any copies made of the front end will copy the links to the tables, and those links contain the path to the back end on the network. If they want to make a private copy of the front and back ends, they have to relink the tables using the Linked Table Manager. This is easy to forget, and if it's not done they could be using a "private" front end and think they're using their "private" back end, while in fact they're using the network back end.

Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein
 
Our agency backs up the network every night supposedly but the last time I had a problem they weren't sure they could get my data back. Not a very reliable back up.

The updates I meant were for changes to the application so you did reassure me on that.

For the private front end, I thought the data entry person could just have a notepad document where she could put in the date the database was last updated. The others who want to make a copy would then be responsible for making their own copies and relinking the tables. They could export any queries they want to keep into the main front end.

Would replication make more sense. It sounds like from what I've read that the back end should be the Design Master. Would the data entry person then synchronize the replicas every time she enters data? In the case the back end is the design master then I assume I'd have to export all the reports, report generator forms, and queries to the replicas that the other two users are using. I could make data entry impossible in those two replicas I assume.

Thanks.
 
I'm not a replication user, because the only time I needed something like that was before it was introduced.

However, from what I understand, your data entry person would actually be the only one updating the back end Design Master. It would be up to the people having replicas of the back end (i.e., the rest of your users) to synchronize their copies.

I don't know what replication does with the design of queries, forms, etc. In any case, though, those things are normally in the front end, so they can be loaded without causing network traffic and so that users can create and modify their own without colliding with other users.

How would you make data entry impossible in certain replicas? The point of replication is that all copies are forced to be identical after synchronization. I don't even think you're allowed to alter the design after you turn on replication, except in the Design Master (hence its name).

Bear in mind that if you activate replication, you will not be able to make design changes in your own private copy and then use that to replace the Design Master. You will only be able to make changes directly in the Design Master. If that's on the network, you'll be developing and testing on the same database your data entry user is updating. Not a good idea. Perhaps you should reconsider using replication.

Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein
 
I think perhaps the first way without replication is the way I'll go. It might be a little bit more complicated for the 2 non entry people but simpler in the long run. Thanks for your input.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top