|
|
|
date: Mon, 10 Apr 2006 13:44:01 -0700,
group: microsoft.public.access.replication
back
Re: Game plan for large scale downtime solution
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.
"David W. Fenton" wrote:
> jonefer wrote in
> news:B4B9746B-E97F-44F7-99E3-3853352110D5@microsoft.com:
>
> > 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.
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/
>
date: Tue, 11 Apr 2006 09:24:55 -0700
author: jonefer
Re: Game plan for large scale downtime solution
jonefer wrote in
news:361F2ECC-6AEA-48CD-93D7-20392054897C@microsoft.com:
> 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
> 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.
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).
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
date: Tue, 11 Apr 2006 14:46:47 -0500
author: David W. Fenton lid
Re: Game plan for large scale downtime solution
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?
"David W. Fenton" wrote:
> jonefer wrote in
> news:361F2ECC-6AEA-48CD-93D7-20392054897C@microsoft.com:
>
> > 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
> > 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.
>
> 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).
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/
>
date: Tue, 11 Apr 2006 13:16:01 -0700
author: jonefer
Re: Game plan for large scale downtime solution
jonefer wrote in
news:D08D1583-3245-4AF8-988C-91C685D3221C@microsoft.com:
> 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?
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.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
date: Tue, 11 Apr 2006 19:37:00 -0500
author: David W. Fenton lid
Re: Game plan for large scale downtime solution
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?
"David W. Fenton" wrote:
> jonefer wrote in
> news:D08D1583-3245-4AF8-988C-91C685D3221C@microsoft.com:
>
> > 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?
>
> 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.
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/
>
date: Tue, 11 Apr 2006 18:21:02 -0700
author: jonefer
Re: Game plan for large scale downtime solution
jonefer wrote in
news:3A299571-A11C-4EF4-A7AA-58210E0BD7DA@microsoft.com:
> 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.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
date: Wed, 12 Apr 2006 07:56:36 -0500
author: David W. Fenton lid
Re: Game plan for large scale downtime solution
Thank you. This was very useful information.
"David W. Fenton" wrote:
> jonefer wrote in
> news:3A299571-A11C-4EF4-A7AA-58210E0BD7DA@microsoft.com:
>
> > 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.
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/
>
date: Thu, 13 Apr 2006 12:16:02 -0700
author: jonefer
|
|
