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

Duplicate db apphend/update 2

Status
Not open for further replies.

Countymnca

Technical User
Jul 18, 2006
44
0
0
US
Hello I am looking for some opinions of those more advanced than I prior to jumping into a possible solution.

A db (Access 2003) exists on one server within my dept. It is accessed by a group of remote users 80 miles away via an intranet as well as users in the same building as the server. As expected, performance for the remote users is terrible with frequent freeze ups, problems and crashes.

I am looking for a way to have duplicate versions of the same db on a server at each location. Then once a day (or as needed) have each db apphend and update each other so that when done, both are identical again.

This is not my db project, but I have been asked for suggestions as performance is bad and upgrading the network is a long way off and outside our control.

My thought is to develop appehend & update queries for the tables that need them and then manually launch it at the end of the day for it to process. Maybe one location runs it at the end of the day and the other location runs it in the morning.

Thanks in advance for any ideas....
 
You could consider Replication, although it can be troublesome. Otherwise, is setting up a website for the remote people an option for you? It is possible, depending on expertise, to put together a few pages of ASP/ASP.Net quite quickly, and if you have a small private site, Access will work well as a backend.
 
The creator of this db is looking at a website, however neither of us have any experience doing that and our tech support is less than helpful with anything. Thus the reason for both of us to learn Access to solve our own problems. There has been talk of moving to SQL Server, but I see no benefit to that as the problem is distance and speed of data, not db ability or power.

I will read up on Replication as I have never used it.
 
moving to SQL Server, but I see no benefit
Access use a file server technology.
MSSQL use a client server technology which is much more suited for distance and speed of data.

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886
 
Ok PHV...let me rephrase....without outside help moving to SQL is not possible. I did mention that our tech support was worthless and consisted of just installing hardware and changing user passwords didnt I?

Unless your post is a secret offer for assistance with moving to SQL, I will keep looking for a possible fix.
 
A commun way is to let the remote people access the DB thru TerminalServer or Citrix.

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886
 
Countymnca,
Given your resources, I would say phv's suggestion for Terminal Services is probably the best and cheapest solution.

If the front-end has any local tables, you just keep separate copies in each user's mydocs or destkop folder, and the backend sits on same server in single location.

If there is no front-end, make one...or more precisely--make the backend with the tables from the original .mdb.

Again, given your resources, I'd stay away from replication and definitely stay away from any manual update-query scheme for home-built 'replication'.
--Jim
 
jsteph & PHV - thanks for the info. I will check into that idea. As of now, no it is not fe/be, but that was my first suggestion to the person who created it. I have done that several times myself, but never outside the building where the server is let alone over that distance.

I agree just a small amount of money could make a big difference, but I dont see it unless I pay for it myself or pass the hat.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top