Game plan for large scale downtime solution

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

jonefer - 10 Apr 2006 21:44 GMT

I have a member database for a large medical company. During network outage
a selected group of individuals - 35 (at most), will access Member Data from
an access database installed on their local drive.

The way we are planning to deploy latest information to these machines is to
have a script that runs a macro that synchronizes with the network copy and
pulls latest member information to these machines.

At first we thought we would do a "Pull" where each employee, upon
successful login to the network would get a 'Delta' of the latest changes fed
to their machine.

But then we considered - what if that employee goes on vacation, and is
unable to get an update - till the next Downtime when they need the latest
data?

It would be more reliable to feed a delta to the designated machine on
scheduled times at least twice a week. Those being 'tagged' for one feed,
would be ineligible for the next feed.

Is this feasable? or is their a better game plan?

If anyone has ironed out how to implement this, or know of any resource of
information for this topic, please share it... thank you.

Reply to this Message

David W. Fenton - 11 Apr 2006 01:15 GMT

> I have a member database for a large medical company. During
> network outage a selected group of individuals - 35 (at most),
[quoted text clipped - 23 lines]
> resource of information for this topic, please share it... thank
> you.

Is this a replication question or not?

Signature

David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Reply to this Message

jonefer - 11 Apr 2006 02:30 GMT

Isn't coordinating synchronization of a huge file(500MB) between 35 machines
a replication question?

If not, please point me to the correct group.

> > I have a member database for a large medical company. During
> > network outage a selected group of individuals - 35 (at most),
[quoted text clipped - 25 lines]
>
> Is this a replication question or not?

Reply to this Message

David W. Fenton - 11 Apr 2006 13:53 GMT

> Isn't coordinating synchronization of a huge file(500MB) between
> 35 machines a replication question?

Well, what you described didn't sound like any use of Jet
replication. It sounded more like programming it yourself.

What is your actual question?

The answer as related to Jet replication will depend on a number of
factors, such as whether the machines are all connected to the same
LAN, or whether they are connected some of the time and not at
others, or whether they are never connected except over a LAN, or
whether they are never connected ever.

Signature

David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Reply to this Message

jonefer - 11 Apr 2006 17:24 GMT

There are various types of outages.
For example, there was a Corona outage in California.

We have an Intranet (LAN) version of this database, and that is what covered
the Corona outage.

We have a Desktop version (which I am speaking about in this subject)
This ACCESSS database is for use during times when any network is totally
unavailable.

So it needs to be able to synchronize, at least weekly, whenever the network
IS available.

My question: I wondered if there was something hidden that I should plan for
besides making sure the users synchronize at least weekly... And if 500MB
database synchronization is a rediculous plan.
It seems rediculous just saying 500MB Access database, but I don't have any
other options at the moment.

> > Isn't coordinating synchronization of a huge file(500MB) between
> > 35 machines a replication question?
[quoted text clipped - 9 lines]
> others, or whether they are never connected except over a LAN, or
> whether they are never connected ever.

Reply to this Message

David W. Fenton - 11 Apr 2006 20:46 GMT

> There are various types of outages.
> For example, there was a Corona outage in California.
>
> We have an Intranet (LAN) version of this database, and that is
> what covered the Corona outage.

The term "Corona outage" is pretty much meaningless to me, but I"ll
assume it means the network was unavailable.

> We have a Desktop version (which I am speaking about in this
> subject) This ACCESSS database is for use during times when any
[quoted text clipped - 8 lines]
> plan. It seems rediculous just saying 500MB Access database, but I
> don't have any other options at the moment.

I don't see any issue with a 500MB Jet database.

As to a synch, if the connection once a week is on a LAN, then they
can do a direct synch, which is very easy to program and very
reliable on a reliable LAN.

It won't be synching 500MBs of data, but it will pull the 500MB
database's headers (if not more than the headers) across the network
to the local machines. This is probably not a big issue at all,
unless you think that 20 people are going to be doing this truly
simultaneously.

If that's an issue, or it's not a LAN connection, you need to go to
indirect replication, which is quite efficient (it sends only the
changes to the remote dropbox, which is why it works over
low-bandwidth connections, including across a VPN over the Internet,
even dialup).

Signature

David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Reply to this Message

jonefer - 11 Apr 2006 21:16 GMT

The "Indirect Synchronization" suggestion is a very helpful suggestion.
A good portion of the users are VPN from a laptop.

I've been successful programming the direct synchronization.
Does it rob performance to always use "Indirect Synchronization", or should
I try to determine whether the users are VPN, vs directly connected to the
network and adjust the type of synchronization appropriately?

I will consult the help about Indirect synchronization, can you suggest any
good articles about Indirect Synchronization?

> > There are various types of outages.
> > For example, there was a Corona outage in California.
[quoted text clipped - 35 lines]
> low-bandwidth connections, including across a VPN over the Internet,
> even dialup).

Reply to this Message

David W. Fenton - 12 Apr 2006 01:37 GMT

> The "Indirect Synchronization" suggestion is a very helpful
> suggestion. A good portion of the users are VPN from a laptop.
[quoted text clipped - 4 lines]
> directly connected to the network and adjust the type of
> synchronization appropriately?

Well, you need to decide where your threshold is for indirect. For
instance, you could have a rule that if a user hasn't been in the
office for a week, they should do an indirect synch. But if they go
into the office weekly, they could do direct synchs while in the
office, and then not need to synch while away.

The way I'd implement it would be to have a UI that gives the user
the choice of a direct or indirect synch. Of course, you'll have to
have some way of distinguishing the VPN connection from the real
one, and I've not thought through that problem before. Perhaps the
IP blocks are different for the two connections?

> I will consult the help about Indirect synchronization, can you
> suggest any good articles about Indirect Synchronization?

It's complex. I would suggest reading the Microsoft Replication
White Paper (skeptically -- it has lots of misleading information in
it), then http://trigeminal.com, then the archives of this
newsgroup.

Signature

David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Reply to this Message

jonefer - 12 Apr 2006 02:21 GMT

Thanks so much.

I have a couple of showstoppers:
1) I assumed I could create an MDE -
but I guess I could programatically keep a user from getting under the hood.

2) It seems as though I need an Access 'Developer' edition to get "Indirect
Syncrhonization" - I thought I could call it in VBA.

Any substitutions?

> > The "Indirect Synchronization" suggestion is a very helpful
> > suggestion. A good portion of the users are VPN from a laptop.
[quoted text clipped - 24 lines]
> it), then http://trigeminal.com, then the archives of this
> newsgroup.

Reply to this Message

David W. Fenton - 12 Apr 2006 13:56 GMT

> I have a couple of showstoppers:
> 1) I assumed I could create an MDE -
> but I guess I could programatically keep a user from getting under
> the hood.

An MDE is for the front end, to remove the code and make
module-bearing objects uneditable. It has no effect on data. For
protecting that, you need to use Jet user-level security.

> 2) It seems as though I need an Access 'Developer' edition to get
> "Indirect Syncrhonization" - I thought I could call it in VBA.

Well, theoretically, you don't need the Developer's toolkit. All you
need is the synchronizer. You can get that by installing the Jet 4
Replication Security update, which installs the two synchronizers
(one for indirect synchronization, one for Internet). Then you can
use the TSI Synchronizer and/or JRO to control them.

If you are using Access 97, then you don't need that -- the
synchronizer is included (with Microsoft's permission) with the Jet
3.5 version of the TSI Synchronizer downloadable from Michael
Kaplan's website, http://trigeminal.com.

However, here's the first problem: the most recent person in these
parts to attempt to use these methods without Replication Manager
installed (the component that you can only get with the Office
developor toolkit). Though there are no programmatic dependencies,
there are apparently some registry keys or configuration settings
somewhere that ReplMan sets that are not set without it.

The second problem is that Microsoft has quite stupidly remoeved all
replication tools from the latest iteration of the Office
development tools (for Office 2K3, it's Visual Studio that's the
development toolkit), so the only way to get ReplMan is to by the
Office XP Developer Edition, which may or may not be available any
more (the Office 2K version would work, too, as all of them are Jet
4.0).

It's not clear that the problem with replication without ReplMan
installed is an insurmountable problem. There is no reason why it
shouldn't be doable. Someone just has to identify exactly what the
problem was that was preventing it.

Signature

David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Reply to this Message

jonefer - 13 Apr 2006 20:16 GMT

Thank you. This was very useful information.

> > I have a couple of showstoppers:
> > 1) I assumed I could create an MDE -
[quoted text clipped - 38 lines]
> shouldn't be doable. Someone just has to identify exactly what the
> problem was that was preventing it.

Reply to this Message