Database across Multiple Sites

dgm

Registered User.
Local time
Tomorrow, 00:18
Joined
Sep 5, 2002
Messages
146
Hi All,
The company I work for has three sites, two close together and the other one half way across the country, each with their own server. Is it possible to have a database that can be used across all three sites? They need to access the same data, so I can't have seperate DB's.

Any help is much appreciated,

Dave
 
Do all your users have access to each server or are they limited to their home server?

I have a situation with 1500 or so users over 20 servers. I have placed an identical copy of the database on each server, sent ourt a VB frontend and overnight run a tool that picks up any amendments/additions made on each database, updates a single table and then copies this table out to the other 19 servers. It's fiddly but works.
 
Seem to have access to only a few folders on the other servers, such as temp. So I guess that would work.

Wouldn't that cause problems if the same record is changed on multiple sites? Although this database will not have that many users and most will only be viewing data anyway, so it's probably not a problem in this case.

Thanks for your help,

Dave
 
What you say about more than one change to a single record on different servers is correct. We currently find about 40 of these cases each evening out of 3000 or so amendments. I'd love to use a single database solution but not possible with Access in our situation and no chance of a more suitable software package. Ho Hum!

Jon.
 
Unfortunately, when you talk about a cross-country connection, you are running major risks by doing data sharing across that network. You are at the whim of lots of factors.

If you get charged by your ISP by the kilobyte, you will incur some really UGLY charges because of the way Access abuses networks for remotely-held files.

Stuff transmitted across a cross-country network is visible by folks who have learned how to tap into passing network traffic. So if there is mission-critical or proprietary data passing along, you are exposing it to the world.

Synchronization across a cross-country network is going to be limited by the slowest link in the network chain between here and there. So you would see pretty poor performance based on that remote data sharing.

My advice to you is that you CANNOT use a single database in this situation if you are bound to Access on each desktop. You MUST include a way to reconcile separate databases on a regular basis, then transmit your reconciliation data as transaction records in a burst mode that minimizes sustained traffic.

This assumes that you don't have something like a direct and private OC3 or DC12 network link among all of your separate sites. If you DO, then the prior arguments aren't so important. But given the big bucks involved with that level of network connection, I'm betting that you don't have that hot a data pipe. If that is the case, you are pretty much hosed with regard to remote data sharing.

Now, there is another way... still ugly but at least doable. If every user MUST see the same data, you can do it through the web. You need a special set of licenses to make it work with Access, but it can be done. Make the hottest server of the bunch the master server for all sites. Then create a bunch of Active Server Pages to provide your forms and other data at that site. Secure it with the something like OpenSSH or one of the other secure transmission layers. Put up a web site that controls access to those pages, give it a good login shell.

Unfortunately, when you are talking "long-distance remote" and "Access" in the same breath, you aren't talking cheap, convenient, secure, or efficient. It is just the nature of the beast.
 
Doc Man, I'm stuck with Access and VB at the moment. When I set an index on a field on a remote server using VBA from my home server it takes quite a while. I'd like to think that my VBA command is sent to the remote server which then acts on the command and returns confirmation to the home server when it's finished involving apparently little data traffic. Is this assumption correct?

Jon.
 
When I set an index on a field on a remote server using VBA from my home server it takes quite a while. I'd like to think that my VBA command is sent to the remote server which then acts on the command and returns confirmation to the home server when it's finished involving apparently little data traffic. Is this assumption correct?

Two cases:

1. The remote server is linked to something like ORACLE, SQLserver, DB2, Sybase, FOCUS, Ingres, RDB ... via ODBC ... Your assumption would probably be correct.

2. The remote server is merely the place where the .MDB file resides, in which case your assumption is not correct.

In case 2 (which is what I believe you have from what I have seen in this thread), your data traffic involves reading the entire data table across the network to your local machine so you can build the index, then sending the entire new index back across to the database file as a new object to be contained therein. Plus various and sundry updates of whatever other pointers Access happens to be keeping in the vicinity of any structures that got modified.

The only thing done locally (local to the REMOTE site) would be the allocation of extra blocks to the file holding the database. I.e. file system operations. And the rewriting of the new blocks is STILL the responsibility of your machine that is local to YOU. So ALL blocks that have to be rewritten in the .MDB file have to go across that link. Remember my earlier comments about how Access abuses the network? This is one example.

If your design does not allow you to change products or change the distant sharing requirements, you have painted yourself into a corner from which there is no reasonable escape.
 
Doc Man, thanks for your explanation - I am in scenario 2. I'm stuck with the distance problem and office politics denies me use of anything but Access 97. I was just curious of the overheads I was placing on the WAN as I'm building an argument for a more suitable software and your explanation certainly helps.

thanks,

Jon.
 

Users who are viewing this thread

Back
Top Bottom