By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,572 Members | 959 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,572 IT Pros & Developers. It's quick & easy.

Access Back-End Over the Internet?

P: n/a
Hi,

I've been using an Access application I wrote for an office with the
front-end stored on all computers and the back-end on one of them serving as
an Access file server.

Now we're moving to a 2nd office 15 minutes down the road. Only one office
will be open at a time, so theoretically it'd be possible to copy the
back-end manually every night from one office to another, but frankly,
that's pretty annoying.

So does anyone have any good Internet suggestions? Some way I can either (a)
have one office use the back-end database off the other computer (one office
has high speed Internet, it could be possible to get high-speed Internet at
the second office as well) or (b) automatically update the back-end database
over the Internet from one computer to the other besides for using something
really manual like e-mail (this needs to be really simple/automatic)?

Thanks.
Nov 13 '05 #1
Share this Question
Share on Google+
56 Replies


P: n/a
Br
Raphi <le**@DELETEME.optonline.net.REMOVE> wrote:
Hi,

I've been using an Access application I wrote for an office with the
front-end stored on all computers and the back-end on one of them
serving as an Access file server.

Now we're moving to a 2nd office 15 minutes down the road. Only one
office will be open at a time, so theoretically it'd be possible to
copy the back-end manually every night from one office to another,
but frankly, that's pretty annoying.

So does anyone have any good Internet suggestions? Some way I can
either (a) have one office use the back-end database off the other
computer (one office has high speed Internet, it could be possible to
get high-speed Internet at the second office as well) or (b)
automatically update the back-end database over the Internet from one
computer to the other besides for using something really manual like
e-mail (this needs to be really simple/automatic)?

Thanks.

Remote control a PC or connect via VPN to one office from the other....

--
regards,

Bradley

A Christian Response
http://www.pastornet.net.au/response
Nov 13 '05 #2

P: n/a
Remote control would be way too slow to use well. How would I set up VPN?

"Br@dley" <n0****@4u.com> wrote in message
news:tD***************@news-server.bigpond.net.au...
Raphi <le**@DELETEME.optonline.net.REMOVE> wrote:
Hi,

I've been using an Access application I wrote for an office with the
front-end stored on all computers and the back-end on one of them
serving as an Access file server.

Now we're moving to a 2nd office 15 minutes down the road. Only one
office will be open at a time, so theoretically it'd be possible to
copy the back-end manually every night from one office to another,
but frankly, that's pretty annoying.

So does anyone have any good Internet suggestions? Some way I can
either (a) have one office use the back-end database off the other
computer (one office has high speed Internet, it could be possible to
get high-speed Internet at the second office as well) or (b)
automatically update the back-end database over the Internet from one
computer to the other besides for using something really manual like
e-mail (this needs to be really simple/automatic)?

Thanks.

Remote control a PC or connect via VPN to one office from the other....

--
regards,

Bradley

A Christian Response
http://www.pastornet.net.au/response

Nov 13 '05 #3

P: n/a
Oh, and I should have mentioned, I'm doing this in Access 97, if it's
relevant.

"Raphi" <le**@DELETEME.optonline.net.REMOVE> wrote in message
news:Fv******************@fe11.lga...
Hi,

I've been using an Access application I wrote for an office with the
front-end stored on all computers and the back-end on one of them serving as an Access file server.

Now we're moving to a 2nd office 15 minutes down the road. Only one office
will be open at a time, so theoretically it'd be possible to copy the
back-end manually every night from one office to another, but frankly,
that's pretty annoying.

So does anyone have any good Internet suggestions? Some way I can either (a) have one office use the back-end database off the other computer (one office has high speed Internet, it could be possible to get high-speed Internet at the second office as well) or (b) automatically update the back-end database over the Internet from one computer to the other besides for using something really manual like e-mail (this needs to be really simple/automatic)?

Thanks.

Nov 13 '05 #4

P: n/a
Br
Raphi <le**@DELETEME.optonline.net.REMOVE> wrote:
Remote control would be way too slow to use well.
Should be ok if you have broadband at each office.....
How would I set up VPN?


To set up a VPN you need Windows2003 server or something similar...

--
regards,

Bradley

A Christian Response
http://www.pastornet.net.au/response
Nov 13 '05 #5

P: n/a
Hmm...any other ideas that can be implemented on Windows XP computers?

"Br@dley" <n0****@4u.com> wrote in message
news:3S****************@news-server.bigpond.net.au...
Raphi <le**@DELETEME.optonline.net.REMOVE> wrote:
Remote control would be way too slow to use well.


Should be ok if you have broadband at each office.....
How would I set up VPN?


To set up a VPN you need Windows2003 server or something similar...

--
regards,

Bradley

A Christian Response
http://www.pastornet.net.au/response

Nov 13 '05 #6

P: n/a
Raphi wrote:
Remote control would be way too slow to use well. How would I set up
VPN?


Why? Have you ever used Terminal Services or PC Anywhere over the internet?
Even with dial-up I have found it quite acceptable. When people talk about
using VPN with Access they mean in conjunction with remote control software.
Using a VPN to run Access over an internet connection as you would normally over
a LAN is NOT going to give acceptable performance and will have a high incidence
of file corruption.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #7

P: n/a
"Raphi" <le**@DELETEME.optonline.net.REMOVE> wrote in message
news:nb******************@fe10.lga...
Remote control would be way too slow to use well. How would I set up VPN?


No, you got it backwards!! a VPN is about 100 times to slow over the
internet. Remote control software is EXACTLY what you need.

Using a wan with ms-access? How fast, how far?

By Albert D. Kallal
Saturday, August 09, 2003

http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

Nov 13 '05 #8

P: n/a
Albert D. Kallal wrote:
"Raphi" <le**@DELETEME.optonline.net.REMOVE> wrote in message
news:nb******************@fe10.lga...
Remote control would be way too slow to use well. How would I set
up VPN?


No, you got it backwards!! a VPN is about 100 times to slow over the
internet. Remote control software is EXACTLY what you need.

Using a wan with ms-access? How fast, how far?


I actually need my VPN in order to run my remote control software. Doesn't
everybody? How else do you gain access to the remote LAN? Surely it is not
simply open to the internet?

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #9

P: n/a
Br
Rick Brandt <ri*********@hotmail.com> wrote:
<>
I actually need my VPN in order to run my remote control software.
Doesn't everybody? How else do you gain access to the remote LAN?


That's how I do it as I need to be logged into the domain.

However, if you are using pcAnywhere for example I'm sure you can
connect directly to the computer.
--
regards,

Bradley

A Christian Response
http://www.pastornet.net.au/response
Nov 13 '05 #10

P: n/a
"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:mh**************@newssvr12.news.prodigy.com.. .

I actually need my VPN in order to run my remote control software.
Doesn't everybody? How else do you gain access to the remote LAN? Surely
it is not simply open to the internet?


I should probably clarify the above. The point here is that a VPN is 100
times slower then your typical office LAN. Thus, you should NOT run a split
database across a LAN. Of course, you most certainly should use a VPN to
make your connection, and that includes the remote desktop connection.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal
Nov 13 '05 #11

P: n/a
Perhaps I'm misunderstanding something, but I'm just drawing from previous
experiences.
This new office needs to have regular functionality, I can't expect workers
to use remote control software that sends screen shots back and forth over
the Internet and has consistent lags in response times to any function
performed. It's infuriating when I use remote control software that
everything you do takes a few seconds longer. On the other hand, my whole
back-end database is ~2 MB, so if I could store that on one computer and
access it via VPN, that would seem to be a lot faster, no? And why is
everyone concerned about data corruption over VPN? I'm sure the VPN protocol
accounts for some sort of error detection (even the underlying TCP protocol
has error correction, IIRC?).

"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:L%**************@newssvr12.news.prodigy.com.. .
Raphi wrote:
Remote control would be way too slow to use well. How would I set up
VPN?
Why? Have you ever used Terminal Services or PC Anywhere over the

internet? Even with dial-up I have found it quite acceptable. When people talk about using VPN with Access they mean in conjunction with remote control software. Using a VPN to run Access over an internet connection as you would normally over a LAN is NOT going to give acceptable performance and will have a high incidence of file corruption.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

Nov 13 '05 #12

P: n/a
"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:mh**************@newssvr12.news.prodigy.com.. .
I actually need my VPN in order to run my remote control software.
Doesn't everybody?
Er, no.
How else do you gain access to the remote LAN?


RemotelyAnywhere? VNC? Secure VNC?

Mike
Nov 13 '05 #13

P: n/a
"Raphi" <le**@DELETEME.optonline.net.REMOVE> wrote in message
news:bk*******************@fe09.lga...
Perhaps I'm misunderstanding something, but I'm just drawing from previous
experiences.
This new office needs to have regular functionality, I can't expect
workers
to use remote control software that sends screen shots back and forth over
the Internet and has consistent lags in response times to any function
performed.
Actually, with any connection that is better then a 56k modem, you users
will likely NOT even notice the difference. The remote desktop in windows is
VERY good. While programs like VNC, or Pc-AnyWhere actually send screen
shots across the net, the remote desktop built onto windows actually only
sends drawing commends, and thus RDP is MUCH MORE efficient then sending
screen shots. We are talking complete different technologies here.

The problem here is that you WAN is 100 times slower then your LAN. While
Remote desktop can happily work with 100 times less bandwidth then your
typical office network, .ms-access cannot!
It's infuriating when I use remote control software that
everything you do takes a few seconds longer.
Have you tried remote desktop that built into windows? Do not confuse such a
solution with products like VNC, or pc-anwayhere.

I suggest you give remote desktop a try. I deployed it many times..and users
generally can't even tell the different between using the application local,
or access the net.

If you have window server 2000 in the office, y ou can actually setup two
free remote users. I believe the same is for windows 2003 server.
On the other hand, my whole
back-end database is ~2 MB, so if I could store that on one computer and
access it via VPN, that would seem to be a lot faster, no?
No, it would be a LOT slower. Remember, we are talking about something that
is 100 times slower.
And why is
everyone concerned about data corruption over VPN? I'm sure the VPN
protocol
accounts for some sort of error detection (even the underlying TCP
protocol
has error correction, IIRC?).


If you are just plotting a web screen or something else, a bit of data
dropping does not matter. And, while error recovery tries it best...as a
general rule you can't rely on this. In a split file share, a bad network,
or even bad cabling in your office will damage the file. Just temporary
dropping the connection can EASILY blow out a ms-access file, and VPN's do
this all the time. Ms-access DOES NOT tolerate a flakey network connection
in anyway, shape or form. You need a rock solid connection to run a split
database. if you can't ensure a rock solid connection, then you have to put
the back end data on a server based system.

Remember, you are opening a file across a internet connection, not
transferring it. This means that you go all kinds of overhead etc, since you
are actually passing file read/write commands over the connection. You are
also passing the "dir" across the net also (so, you got a LOT of overhead
here).

Anyway...see my other post of a link that explains this....

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal
Nov 13 '05 #14

P: n/a
Do you need a server (Win 2K or Win 2003) to run Remote Desktop, or can a
Win XP (Home? Pro?) computer host a remote desktop connection as well?
"Albert D. Kallal" <ka****@msn.com> wrote in message
news:CsGfe.1292398$8l.667881@pd7tw1no...
"Raphi" <le**@DELETEME.optonline.net.REMOVE> wrote in message
news:bk*******************@fe09.lga...
Perhaps I'm misunderstanding something, but I'm just drawing from previous experiences.
This new office needs to have regular functionality, I can't expect
workers
to use remote control software that sends screen shots back and forth over the Internet and has consistent lags in response times to any function
performed.
Actually, with any connection that is better then a 56k modem, you users
will likely NOT even notice the difference. The remote desktop in windows

is VERY good. While programs like VNC, or Pc-AnyWhere actually send screen
shots across the net, the remote desktop built onto windows actually only
sends drawing commends, and thus RDP is MUCH MORE efficient then sending
screen shots. We are talking complete different technologies here.

The problem here is that you WAN is 100 times slower then your LAN. While
Remote desktop can happily work with 100 times less bandwidth then your
typical office network, .ms-access cannot!
It's infuriating when I use remote control software that
everything you do takes a few seconds longer.
Have you tried remote desktop that built into windows? Do not confuse such

a solution with products like VNC, or pc-anwayhere.

I suggest you give remote desktop a try. I deployed it many times..and users generally can't even tell the different between using the application local, or access the net.

If you have window server 2000 in the office, y ou can actually setup two
free remote users. I believe the same is for windows 2003 server.
On the other hand, my whole
back-end database is ~2 MB, so if I could store that on one computer and
access it via VPN, that would seem to be a lot faster, no?
No, it would be a LOT slower. Remember, we are talking about something

that is 100 times slower.
And why is
everyone concerned about data corruption over VPN? I'm sure the VPN
protocol
accounts for some sort of error detection (even the underlying TCP
protocol
has error correction, IIRC?).
If you are just plotting a web screen or something else, a bit of data
dropping does not matter. And, while error recovery tries it best...as a
general rule you can't rely on this. In a split file share, a bad network,
or even bad cabling in your office will damage the file. Just temporary
dropping the connection can EASILY blow out a ms-access file, and VPN's do
this all the time. Ms-access DOES NOT tolerate a flakey network connection
in anyway, shape or form. You need a rock solid connection to run a split
database. if you can't ensure a rock solid connection, then you have to

put the back end data on a server based system.

Remember, you are opening a file across a internet connection, not
transferring it. This means that you go all kinds of overhead etc, since you are actually passing file read/write commands over the connection. You are
also passing the "dir" across the net also (so, you got a LOT of overhead
here).

Anyway...see my other post of a link that explains this....

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

Nov 13 '05 #15

P: n/a
Also, is Remote Desktop secure, or am I showing my data to the whole world?
"Albert D. Kallal" <ka****@msn.com> wrote in message
news:CsGfe.1292398$8l.667881@pd7tw1no...
"Raphi" <le**@DELETEME.optonline.net.REMOVE> wrote in message
news:bk*******************@fe09.lga...
Perhaps I'm misunderstanding something, but I'm just drawing from previous experiences.
This new office needs to have regular functionality, I can't expect
workers
to use remote control software that sends screen shots back and forth over the Internet and has consistent lags in response times to any function
performed.
Actually, with any connection that is better then a 56k modem, you users
will likely NOT even notice the difference. The remote desktop in windows

is VERY good. While programs like VNC, or Pc-AnyWhere actually send screen
shots across the net, the remote desktop built onto windows actually only
sends drawing commends, and thus RDP is MUCH MORE efficient then sending
screen shots. We are talking complete different technologies here.

The problem here is that you WAN is 100 times slower then your LAN. While
Remote desktop can happily work with 100 times less bandwidth then your
typical office network, .ms-access cannot!
It's infuriating when I use remote control software that
everything you do takes a few seconds longer.
Have you tried remote desktop that built into windows? Do not confuse such

a solution with products like VNC, or pc-anwayhere.

I suggest you give remote desktop a try. I deployed it many times..and users generally can't even tell the different between using the application local, or access the net.

If you have window server 2000 in the office, y ou can actually setup two
free remote users. I believe the same is for windows 2003 server.
On the other hand, my whole
back-end database is ~2 MB, so if I could store that on one computer and
access it via VPN, that would seem to be a lot faster, no?
No, it would be a LOT slower. Remember, we are talking about something

that is 100 times slower.
And why is
everyone concerned about data corruption over VPN? I'm sure the VPN
protocol
accounts for some sort of error detection (even the underlying TCP
protocol
has error correction, IIRC?).
If you are just plotting a web screen or something else, a bit of data
dropping does not matter. And, while error recovery tries it best...as a
general rule you can't rely on this. In a split file share, a bad network,
or even bad cabling in your office will damage the file. Just temporary
dropping the connection can EASILY blow out a ms-access file, and VPN's do
this all the time. Ms-access DOES NOT tolerate a flakey network connection
in anyway, shape or form. You need a rock solid connection to run a split
database. if you can't ensure a rock solid connection, then you have to

put the back end data on a server based system.

Remember, you are opening a file across a internet connection, not
transferring it. This means that you go all kinds of overhead etc, since you are actually passing file read/write commands over the connection. You are
also passing the "dir" across the net also (so, you got a LOT of overhead
here).

Anyway...see my other post of a link that explains this....

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

Nov 13 '05 #16

P: n/a
Mike MacSween wrote:
"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:mh**************@newssvr12.news.prodigy.com.. .
I actually need my VPN in order to run my remote control software.
Doesn't everybody?


Er, no.
How else do you gain access to the remote LAN?


RemotelyAnywhere? VNC? Secure VNC?


Yes, I have used them all, but I cannot get to my corporate LAN with any of
those unless I first establish a VPN connection and I have to use SecureRemote
software to do that. This is where you have a small device that displayes a 6
digit numerical sequence that changes every 60 seconds and I have to provide
that sequence as well as a password and PIN before I can connect.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #17

P: n/a
<snip>

So does anyone have any good Internet suggestions? Some way I can either
(a)
have one office use the back-end database off the other computer (one
office
has high speed Internet, it could be possible to get high-speed Internet
at
the second office as well) or (b) automatically update the back-end
database
over the Internet from one computer to the other besides for using
something
really manual like e-mail (this needs to be really simple/automatic)?

Thanks.


Sounds like this would be a great time to use Replication.
John
Nov 13 '05 #18

P: n/a
"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:D%***************@newssvr12.news.prodigy.com. ..
> How else do you gain access to the remote LAN?


RemotelyAnywhere? VNC? Secure VNC?


Yes, I have used them all, but I cannot get to my corporate LAN with any
of those unless I first establish a VPN connection and I have to use
SecureRemote software to do that. This is where you have a small device
that displayes a 6 digit numerical sequence that changes every 60 seconds
and I have to provide that sequence as well as a password and PIN before I
can connect.


Never had to do that. One method is to use RemotelyAnywhere to get to one
machine on the remote LAN, then VNC out to other machines on the LAN from
there. Because RemotelyAnywhere is secure and plain old VNC isn't, so they
say.

Might it depend how the LAN/Firewall you're trying to connect to and through
are set up?

Mike
Nov 13 '05 #19

P: n/a
could use port forwarding if you have a router. think even a simple
linksys/netgear has that functionality. Just not sure what port you need to
connect to an Access db. Thats one way to access machines on a LAN without a
VPN.

But that will force all traffic using that port to go to that machine

"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:mh**************@newssvr12.news.prodigy.com.. .
Albert D. Kallal wrote:
"Raphi" <le**@DELETEME.optonline.net.REMOVE> wrote in message
news:nb******************@fe10.lga...
Remote control would be way too slow to use well. How would I set
up VPN?
No, you got it backwards!! a VPN is about 100 times to slow over the
internet. Remote control software is EXACTLY what you need.

Using a wan with ms-access? How fast, how far?


I actually need my VPN in order to run my remote control software.

Doesn't everybody? How else do you gain access to the remote LAN? Surely it is not simply open to the internet?

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

Nov 13 '05 #20

P: n/a
On Sun, 8 May 2005 19:19:53 -0400, "Raphi"
<le**@DELETEME.optonline.net.REMOVE> wrote:
Remote control would be way too slow to use well. How would I set up VPN?


Actually, remote control should be usable. Trying to share your Access
back-end across the network, on the other hand - that would be slow.

Nov 13 '05 #21

P: n/a
"Steve Jorgensen" wrote
Trying to share your Access
back-end across the network, on
the other hand - that would be
slow.
****


Steve, I think you misspelled "excruciatingly painful". <G,D,&R>
Nov 13 '05 #22

P: n/a
"John A. Mason" wrote
Sounds like this would be a
great time to use Replication.


Replication is not for the faint of heart.

Larry Linson
Microsoft Access MVP

Nov 13 '05 #23

P: n/a
"Br@dley" <n0****@4u.com> wrote in
news:3S****************@news-server.bigpond.net.au:
Raphi <le**@DELETEME.optonline.net.REMOVE> wrote:
Remote control would be way too slow to use well.


Should be ok if you have broadband at each office.....
How would I set up VPN?


To set up a VPN you need Windows2003 server or something
similar...


No, you don't.

A VPN is a network layer that is entirely independent of the OS of
your servers and workstations. All you need is a router that can
support a VPN and appropriate client software on the workstations.

Of course, a VPN does *not* resolve the issue in any way shape or
form, it only provides a secure tunnel through which you can connect
from one office network to the other.

Windows Terminal Server is the best answer here, with a Windows 2K3
Server running it in one of the offices, and the remote office
running the app on WTS across a VPN. The performance is just fine
with even low-end DSL (e.g., 384K DSL), though it might be dodgy on
mere dialup.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #24

P: n/a
"Albert D. Kallal" <ka****@msn.com> wrote in
news:CsGfe.1292398$8l.667881@pd7tw1no:
I suggest you give remote desktop a try. I deployed it many
times..and users generally can't even tell the different between
using the application local, or access the net.


Well, I doubt that. There are certain screen drawing and color
mapping issues and certain incompatibilities with check boxes
displaying improperly that make it quite clear that you're not
running locally.

Neither of them is enough to be a problem, but the differences are
sufficient to make it clear that it's not the same as running
locally.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #25

P: n/a
"Raphi" <le**@DELETEME.optonline.net.REMOVE> wrote in
news:4H*******************@fe10.lga:
Do you need a server (Win 2K or Win 2003) to run Remote Desktop,
or can a Win XP (Home? Pro?) computer host a remote desktop
connection as well?


For any practical use, unless there's only one user per desktop in
each office and there's never people in both offices, yes, you need
a Windows Terminal Server. WinXP allows one user at a time to
connect via RDP, and the screen of the PC is not accessible while a
remote user is connected. If you have one user with two PCs in two
different offices, then, yes, that would work, since it's a 1:1
connection between PCs and always one way (from A to B or from B to
A) and never with a user at both PCs at the same time.

Also, if you have 3 users and 3 PCs in both locations, then, yes,
that would work, too.

But it's not the most robust solution and has no room for growth.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #26

P: n/a
"Raphi" <le**@DELETEME.optonline.net.REMOVE> wrote in
news:QK*******************@fe10.lga:
Also, is Remote Desktop secure, or am I showing my data to the
whole world?


Depends on how you configure it.

If you run it with the WTS port exposed directly to the Internet
(either directly or through your firewall), then it's not terribly
safe, though those attempting to connect would still have to log on.
If you have non-obvious usernames and strong passwords, you're
relatively safe (though you'd probably want to check the security
setup very carefully before doing this).

However, I'd not consider this scenario with a
workstation-to-workstation setup (as you were contemplating with
WinXP to WinXP and no server) -- the default security setup of WinXP
workstation is not good enough to be exposed directly to the
Internet. Win2K3 server is safer, though.

To be reasonably safe, though, you need the VPN. That way you're
setting up a secure tunnel for your connection between sites, and no
one who is not authorized to connect to that VPN will be able to get
in.

I would never recommend setting up WTS without a VPN, though I do
have two clients who do it without it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #27

P: n/a
"Albert D. Kallal" <ka****@msn.com> wrote in
news:m9Afe.1287106$Xk.1087575@pd7tw3no:
"Raphi" <le**@DELETEME.optonline.net.REMOVE> wrote in message
news:nb******************@fe10.lga...
Remote control would be way too slow to use well. How would I set
up VPN?


No, you got it backwards!! a VPN is about 100 times to slow over
the internet. Remote control software is EXACTLY what you need.


Actually, he needs both, and WTS should be accessed across the VPN.

With a VPN, it's as though you're connected to the remote LAN, but
with a very slow network card. But nobody can see what you're doing
and you don't have to open up the WTS port to the Internet.

That's a much more secure architecture, and also provides local
network functionality to the remote user (which means accessing
network resources directly from the remote PC, though much more
slowly than on the LAN).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #28

P: n/a
"Albert D. Kallal" <ka****@msn.com> wrote in
news:FrAfe.1287566$Xk.933754@pd7tw3no:
"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:mh**************@newssvr12.news.prodigy.com.. .

I actually need my VPN in order to run my remote control
software. Doesn't everybody? How else do you gain access to the
remote LAN? Surely it is not simply open to the internet?
I should probably clarify the above. The point here is that a VPN
is 100 times slower then your typical office LAN. . ..


No, VPNs do not have speed limitations (well, except for the slight
loss of performance due to encryption). You could have VPN
connections on a LAN, which would be running at the speed of the
LAN.

Of course, there's not much reason to do that, since you don't need
privacy within your LAN, in most cases. However, I could see doing
it within a large organization for applications needing high
security.
. . . Thus, you should
NOT run a split database across a LAN. . .
You mean "across a WAN."
. . . Of course, you most
certainly should use a VPN to make your connection, and that
includes the remote desktop connection.


VPNs don't have anything to do with LAN vs. WAN, though they are
most often run over WANs, since the whole point is to provide
privacy on a public network (e.g., the Internet).

The WTS connection should very definitely be initiated across a VPN,
rather than directly on the Internet, if you have any regard for
safety.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #29

P: n/a
"Steve" <1@2.com> wrote in
news:ur*************@newsread3.news.atl.earthlink. net:
could use port forwarding if you have a router. think even a
simple linksys/netgear has that functionality. Just not sure what
port you need to connect to an Access db. Thats one way to access
machines on a LAN without a VPN.
Eh? There is no port associated with Access databases, as Access is
not a db server.
But that will force all traffic using that port to go to that
machine


This has zilch to do with running an Access application across a
WAN.

The only way to do that is to use a form of remote control. The only
good remote control is Windows Terminal Server.

It seems that most of the people replying in this thread know little
or nothing about networking and security.

(an alternative that no one has mentioned is Jet replication, but I
wouldn't recommend that myself, as for a WAN connection, you'd have
to use indirect replication, and that's very tricky to set up)

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #30

P: n/a
"John A. Mason" <ja*******@MYearthlink.net> wrote in
news:6w*************@newsread2.news.atl.earthlink. net:
<snip>

So does anyone have any good Internet suggestions? Some way I can
either (a)
have one office use the back-end database off the other computer
(one office
has high speed Internet, it could be possible to get high-speed
Internet at
the second office as well) or (b) automatically update the
back-end database
over the Internet from one computer to the other besides for
using something
really manual like e-mail (this needs to be really
simple/automatic)?


Sounds like this would be a great time to use Replication.


If you aren't experienced with Replication, this is a very bad idea.

I've recently outlined the details on this which you can read on
Google Groups (all on one line, of course):

http://groups-beta.google.com/group/...ccess/browse_f
rm/thread/86367765e66e1ee4

I would recommend Windows Terminal Server for the described
situation, and I've got years of replication experience under my
belt (I've been doing it since 1997).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #31

P: n/a
Some clarification.

To run Access remotely, over a WAN, it is best to use remote access software
(via Windows XP remote desktop, PcAnyWhere, Radmin, VNC, etc ...) instead of
using a VPN to connect your local Access front-end to a remote Access
back-end. Remote access has quicker performance, and provides for a more
stable operation (e.g. in case you are disconnected from the WAN).

If your remote PC (e.g. the PC in your office with the Access data) has a
"routable" IP address (an IP address seen to the outside world), you can
connect directly to the PC. You still may need to open port(s) in any
firewalls that the PC is behind, including Windows XP firewall.

If your remote PC does not have a "routable" IP address, it is most likely
behind a router that is using a NAT scheme. You can either
1) Configure the router so that the port used by the remote access program
is directed to the remote PC's internal IP address, or
2) Connect via an VPN, and then access the remote PC via its internal IP
address.

Some remote access software allow you to use different ports; this will
allow for multiple users to access multiple remote PCs behind one router
using port redirection. However, I don't think Windows XP remote desktop
has this ability, so if you have multiple remote PCs, connecting initially
via VPN may be required for XP remote desktop. The other draw back with
Windows XP remote desktop is that it only allow for one user to
view/interact with the desktop at one time. PcAnyWhere and other programs
allow for multiple users to view/interact with the desktop at one time;
however, all users are running the same programs.

In our office we use Windows Terminal Server which is similar to Windows XP
remote desktop, but allows for multiple users to access the same server,
interacting with the same session at one time, or running different
sessions, at the same time. I can log on to the WTS and observed a user
working, or open up my own session and work indepently. Not only are we
using it for remote access, but allow users on older PCs to run software
that would choke them. Even though I could easily have set up the WTS with
its own routable IP address, or redirected all RDP requests to it, we still
use VPN for the initial access, and then the user can access the WTS using
the internal IP address (or DNS name).
--
Steven R. Zuch, CPA
Principal
Cogent Management Inc.


"Steve" <1@2.com> wrote in message
news:ur*************@newsread3.news.atl.earthlink. net...
could use port forwarding if you have a router. think even a simple
linksys/netgear has that functionality. Just not sure what port you need
to
connect to an Access db. Thats one way to access machines on a LAN without
a
VPN.

But that will force all traffic using that port to go to that machine

"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:mh**************@newssvr12.news.prodigy.com.. .
Albert D. Kallal wrote:
> "Raphi" <le**@DELETEME.optonline.net.REMOVE> wrote in message
> news:nb******************@fe10.lga...
> > Remote control would be way too slow to use well. How would I set
> > up VPN?
>
> No, you got it backwards!! a VPN is about 100 times to slow over the
> internet. Remote control software is EXACTLY what you need.
>
> Using a wan with ms-access? How fast, how far?


I actually need my VPN in order to run my remote control software.

Doesn't
everybody? How else do you gain access to the remote LAN? Surely it is

not
simply open to the internet?

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com


Nov 13 '05 #32

P: n/a
OK, so I've gotten the feeling from everyone on the newsgroup that the way
to go is to use Remote Desktop on Windows XP (it's only 2 computers, and
they don't need to be used simultaneously, so no need for Terminal Server,
right?). My computer is on a Linksys Broadband Router, which I've tested
online and it provides pretty good security. I suppose I'd just forward the
Remote Desktop IP to that computer (anyone know that port it is?). So do I
need VPN to secure it as well, or is the router security still OK? And
Windows XP doesn't have built in VPN server support, right? So I'd need
another program to run in XP as a VPN server? What port is that, anyway?
Thanks everyone.
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...
"Albert D. Kallal" <ka****@msn.com> wrote in
news:m9Afe.1287106$Xk.1087575@pd7tw3no:
"Raphi" <le**@DELETEME.optonline.net.REMOVE> wrote in message
news:nb******************@fe10.lga...
Remote control would be way too slow to use well. How would I set
up VPN?


No, you got it backwards!! a VPN is about 100 times to slow over
the internet. Remote control software is EXACTLY what you need.


Actually, he needs both, and WTS should be accessed across the VPN.

With a VPN, it's as though you're connected to the remote LAN, but
with a very slow network card. But nobody can see what you're doing
and you don't have to open up the WTS port to the Internet.

That's a much more secure architecture, and also provides local
network functionality to the remote user (which means accessing
network resources directly from the remote PC, though much more
slowly than on the LAN).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #33

P: n/a
"Raphi" <le**@DELETEME.optonline.net.REMOVE> wrote in
news:gl**************@fe12.lga:
OK, so I've gotten the feeling from everyone on the newsgroup that
the way to go is to use Remote Desktop on Windows XP (it's only 2
computers, and they don't need to be used simultaneously, so no
need for Terminal Server, right?). My computer is on a Linksys
Broadband Router, which I've tested online and it provides pretty
good security. I suppose I'd just forward the Remote Desktop IP to
that computer (anyone know that port it is?). So do I need VPN to
secure it as well, or is the router security still OK? And Windows
XP doesn't have built in VPN server support, right? So I'd need
another program to run in XP as a VPN server? What port is that,
anyway? Thanks everyone.


Many recent Linksys routers support VPNs. My guess is that the
built-in VPN client supports it, otherwise it would make little
sense to bundle VPN in a consumer-level router. I'd check Linksys's
website about this.

And I would definitely *not* recommend connecting to WinXP across
the Internet without a VPN. Connecting to a server version of
Windows is insecure enough, but WinXP is terribly insecure in any
number of ways and should not have any ports exposed directly the
Internet.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #34

P: n/a
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...
I should probably clarify the above. The point here is that a VPN
is 100 times slower then your typical office LAN. . ..


No, VPNs do not have speed limitations (well, except for the slight
loss of performance due to encryption). You could have VPN
connections on a LAN, which would be running at the speed of the
LAN.


yes, of course I meant using a VPN over the net in this case (there is
certainly nothing special about speed of a VPN).
. . . Thus, you should
NOT run a split database across a LAN. . .


You mean "across a WAN."


Yes.... a typo (thank you kindly for catching this one!!)
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal
Nov 13 '05 #35

P: n/a
Remote Desktop Port: TCP 3389.

If you setup your PC for Remote Desktop, it will open the port in your
Windows XP firewall.

I use the NAT forwarding scheme in my router, for my home PC. It allows me
to specify a static source IP (which is my work IP), and along with the
normal sign-on logins/passwords, it is ample security based on needs.

A secured VPN would offer more security, as others had stated. For work, we
only allow Remote Desktop either to our Terminal Server or a XP workstation
via VPN. But I find it limiting to state that you should never use remote
control software without a VPN.

Steven R. Zuch, CPA
Cogent Management Inc.

"Raphi" <le**@DELETEME.optonline.net.REMOVE> wrote in message
news:gl**************@fe12.lga...
OK, so I've gotten the feeling from everyone on the newsgroup that the way
to go is to use Remote Desktop on Windows XP (it's only 2 computers, and
they don't need to be used simultaneously, so no need for Terminal Server,
right?). My computer is on a Linksys Broadband Router, which I've tested
online and it provides pretty good security. I suppose I'd just forward
the
Remote Desktop IP to that computer (anyone know that port it is?). So do I
need VPN to secure it as well, or is the router security still OK? And
Windows XP doesn't have built in VPN server support, right? So I'd need
another program to run in XP as a VPN server? What port is that, anyway?
Thanks everyone.
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...
"Albert D. Kallal" <ka****@msn.com> wrote in
news:m9Afe.1287106$Xk.1087575@pd7tw3no:
> "Raphi" <le**@DELETEME.optonline.net.REMOVE> wrote in message
> news:nb******************@fe10.lga...
>> Remote control would be way too slow to use well. How would I set
>> up VPN?
>
> No, you got it backwards!! a VPN is about 100 times to slow over
> the internet. Remote control software is EXACTLY what you need.


Actually, he needs both, and WTS should be accessed across the VPN.

With a VPN, it's as though you're connected to the remote LAN, but
with a very slow network card. But nobody can see what you're doing
and you don't have to open up the WTS port to the Internet.

That's a much more secure architecture, and also provides local
network functionality to the remote user (which means accessing
network resources directly from the remote PC, though much more
slowly than on the LAN).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc


Nov 13 '05 #36

P: n/a
"Steven Zuch" <st***@nospam.net> wrote in
news:Pd***********@fe08.lga:
But I find it limiting to state that you should never use remote
control software without a VPN.


Properly securing your network generally limits certain choices that
would open vulnerabilities on your network.

That's why it's called "security."

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #37

P: n/a
Br
David W. Fenton <dX********@bway.net.invalid> wrote:
"Br@dley" <n0****@4u.com> wrote in
news:3S****************@news-server.bigpond.net.au: <>
How would I set up VPN?
To set up a VPN you need Windows2003 server or something
similar...

No, you don't.

A VPN is a network layer that is entirely independent of the OS of
your servers and workstations. All you need is a router that can
support a VPN and appropriate client software on the workstations.


I was mistaken. I thought you could only create incoming VPN connections
in WinXP....

For the original poster the "how" is probably important...

- Go to Network Connections.

- Run the "Create a New Connection" wizard.

- Outbound VPN connection -> select "Connect to the network at my
workplace"

- Inbound VPN connection -> select "Set up an advanced connection", then
"Accept incoming connections"

You should be able to work out the rest :)

ps. You need a static IP address for your "server" computer, or use a
service like http://dyndns.org which binds a dynamic IP to a domain
name. My ADSL modem/router has inbuilt support for this service (setup
on the router's config pages), else you can download a small tool that
sends IP address updates to their server.

<>
--
regards,

Bradley

A Christian Response
http://www.pastornet.net.au/response
Nov 13 '05 #38

P: n/a
>
Sounds like this would be a
great time to use Replication.


Replication is not for the faint of heart.

Larry Linson
Microsoft Access MVP


So be it. Many folks would say that Access (and databases in general) are
not for the 'faint of heart'.
Microsoft put replication in Access because it has a place and is useful.
It's totally appropriate to consider all of the options available for use
when considering how to solve a problem. In the case mentioned in this
thread, I'm hearing all kinds of advice on how to 'solve' this problem...
all of them off on a tangent and talking about things that are far removed
from Access's needs. Replication is the most effective solution to the OP's
problem.

If someone really wants to use Access effectively, in many situations
replication is going to be appropriate to use. It's just another thing to
learn. Once learned, you become a more effective developer. One important
point to remember is that Replication is most effective when used in a
front-end/back-end configuration. Replicate the back-end/tables only.
Changes to the front-end/application are more effectively applied using
other methods.

Microsoft provides many good tools, explanations, and presentations (along
with other vendors). It's also covered in many Access books. Like most
things database-related, it requires insight, a bit of dedication, and
paying attention to detail. It is not brain surgery. To be honest, it's not
any harder than learning how to properly design a database and it's easier
(in my opinion) than learning how to use full Access security.

Here's some opportunities to pursue:
http://support.microsoft.com/default...b;en-us;136134

-Read this FAQ (actually applies substantially to all versions of Access):
http://support.microsoft.com/default...b;en-us;182886
As with most things related to Access, there are increasing levels of
detail/difficulty. At it's core, Replication is very easy to implement and
use on a daily basis. Getting up and over the learning curve yields great
rewards.

-Whitepaper on Internet Replication (again, even though specific to Access
97, much is applicable to all versions):
http://support.microsoft.com/default...b;en-us;181371

Two of my favorite developer books for Access cover Replication nicely:
http://www.amazon.com/exec/obidos/AS...124153-8133656
Litwin/Getz/Gilbert (Chapter 9)

http://www.amazon.com/exec/obidos/AS...124153-8133656
Balter (Chapter 23)

Best,
John


Nov 13 '05 #39

P: n/a
>>>
So does anyone have any good Internet suggestions? Some way I can
either (a)
have one office use the back-end database off the other computer
(one office
has high speed Internet, it could be possible to get high-speed
Internet at
the second office as well) or (b) automatically update the
back-end database
over the Internet from one computer to the other besides for
using something
really manual like e-mail (this needs to be really
simple/automatic)?


Sounds like this would be a great time to use Replication.


If you aren't experienced with Replication, this is a very bad idea.

I've recently outlined the details on this which you can read on
Google Groups (all on one line, of course):

http://groups-beta.google.com/group/...ccess/browse_f
rm/thread/86367765e66e1ee4

David,
Don't we all start off 'inexperienced'? We live and learn. This is simply a
matter of knowing what tools are available to accomplish the job correctly
and then learning the tool. Please see my other response for details.

I used Replication on a daily basis to connect 4 Access backends over a
LAN/WAN. The backends consisted of 87 tables and were about 25 mb in size.
Over a LAN, the synchronizations were very quick... on the order of seconds.
Over the WAN (700 miles between sites, for whatever that's worth), the
replications took longer... on the order of 3-5 minutes depending on
conditions.

I cannot ever remember losing data to corruption. In the environment this
database was in (i.e. not real time/not everyone writing to the same records
at the same time), I infrequently had synchronization conflicts... and those
that occurred were easily solved.

Regards,
John
Nov 13 '05 #40

P: n/a
>><snip>

So does anyone have any good Internet suggestions? Some way I can
either (a)
have one office use the back-end database off the other computer
(one office
has high speed Internet, it could be possible to get high-speed
Internet at
the second office as well) or (b) automatically update the
back-end database
over the Internet from one computer to the other besides for
using something
really manual like e-mail (this needs to be really
simple/automatic)?


Sounds like this would be a great time to use Replication.


If you aren't experienced with Replication, this is a very bad idea.

I've recently outlined the details on this which you can read on
Google Groups (all on one line, of course):

http://groups-beta.google.com/group/...ccess/browse_f
rm/thread/86367765e66e1ee4

David,
I've read the thread in the Google groups you mention above. I'm not sure I
follow your advice here ('...bad idea'). You obviously know Replication at
least as well as I do. Have you *always* known it this well? Of course
not... you had to start somewhere and learn it. The advice you gave to the
poster on Google was excellent and very useful for anyone
needing/considering Replication. Wouldn't a similar answer here, to the OP,
be appropriate?
Thoughts?
Regards,
John
Nov 13 '05 #41

P: n/a
"John A. Mason" <ja*******@MYearthlink.net> wrote in
news:ql***************@newsread2.news.atl.earthlin k.net:
> Sounds like this would be a
> great time to use Replication.
Replication is not for the faint of heart.

Larry Linson
Microsoft Access MVP


So be it. Many folks would say that Access (and databases in
general) are not for the 'faint of heart'.
Microsoft put replication in Access because it has a place and is
useful. It's totally appropriate to consider all of the options
available for use when considering how to solve a problem. In the
case mentioned in this thread, I'm hearing all kinds of advice on
how to 'solve' this problem... all of them off on a tangent and
talking about things that are far removed from Access's needs.
Replication is the most effective solution to the OP's problem.


So *you* say. I assume, then, that you have extensive experience
with replication?

I *do* have such experience (I've been designing and supported
applications that use replication since 1997).

And I think the best solution is remote desktop or Windows Terminal
Server, both run across a VPN. It's *much* easier to set up and
configure than replication, and far, far more robust in the long
run.
If someone really wants to use Access effectively, in many
situations replication is going to be appropriate to use. It's
just another thing to learn. Once learned, you become a more
effective developer. One important point to remember is that
Replication is most effective when used in a front-end/back-end
configuration. Replicate the back-end/tables only. Changes to the
front-end/application are more effectively applied using other
methods.
It's not a matter of "most effective" with back end only --
replication SHOULD NEVER EVER BE USED ON A FRONT END. Period.

This is precisely the kind of thing that rookies to replication will
get wrong (because the Microsoft documentation on the subject IS
WRONG). And it's but one example of the many pitfalls of
replication.

And replicating the front end can lead to COMPLETE CORRUPTION AND
LOSS of the front end project, requiring reversion to a backup,
which whill probably corrupt itself after a few more
synchronizations, anyway.
Microsoft provides many good tools, explanations, and
presentations (along with other vendors). It's also covered in
many Access books. . . .
And almost all of this documentation, either MS's or 3rd-party
books, is not based on real front-line experience with replication,
but on people who kinda tried it out to see how it works, following
the Microsoft documentation (which is filled with misleading
recommendations and outright errors, most of the latter because the
documentation was written long before people had long-term
experience using replication, and had not yet encountered the common
problems associated with it).

Don't trust *any* of these sources on the subject of replication,
especially Microsoft.

The only sources to trust are:

1. Michael Kaplan's website, http://www.trigeminal.com.

2. the newsgroup microsoft.public.access.replication.
. . . Like most things database-related, it requires
insight, a bit of dedication, and paying attention to detail. It
is not brain surgery. To be honest, it's not any harder than
learning how to properly design a database and it's easier (in my
opinion) than learning how to use full Access security.
I think you're completely wrong.
Here's some opportunities to pursue:
http://support.microsoft.com/default...b;en-us;136134
This doesn't even begin to get you started. It's barely illuminating
than the Access help files.
-Read this FAQ (actually applies substantially to all versions of
Access):
http://support.microsoft.com/default...b;en-us;182886
While that's an important document, it is still filled with
information that is covered by marketing agendas.

And if you think a FAQ about Jet3.5 replication is going to be
helpful with Jet 4.0 replication, then you really don't know a
damned thing about Jet replication overall. Microsoft made major
important (and excellent) changes to the way replication works in
Jet 4.0, and that FAQ won't help you on that at all. Indeed, it will
cause you to go down the wrong path on a number of issues (its
explanation of conflicts is completely out of date, because of
column-level conflict resolution and the completely different model
of what constitutes a conflict in Jet 4.0).
. . . As
with most things related to Access, there are increasing levels of
detail/difficulty. At it's core, Replication is very easy to
implement and use on a daily basis. Getting up and over the
learning curve yields great rewards.
YOU ARE SIMPLY WRONG.
-Whitepaper on Internet Replication (again, even though specific
to Access 97, much is applicable to all versions):
http://support.microsoft.com/default...b;en-us;181371
Again, you're recommending an article that's good for the specific
subject it covers, but that is *not* good for more recent versions
of Jet.
Two of my favorite developer books for Access cover Replication
nicely:
http://www.amazon.com/exec/obidos/ASIN/0782123724/qid% 3D1115820314/ sr%3D11-1/ref%3Dsr%5F11%5F1/002-1124153-8133656
Litwin/Getz/Gilbert (Chapter 9)
They don't really do replication. They just checked it out enough to
write a book on it. There's nothing in their books that does
anything other than rehashing of Microsoft documentation. That's the
result of the process that gets these books published at the same
time the product ships -- it can't possibly reflect real experience
with the product, as the product isn't yet out.
http://www.amazon.com/exec/obidos/ASIN/0672314843/qid% 3D1115820400/ sr%3D11-1/ref%3Dsr%5F11%5F1/002-1124153-8133656 Balter (Chapter
23)


I don't know who Alison Balter is, but I know she's no expert on Jet
replication. The recognized experts in that field are Michael Kaplan
and Mary Chipman. And recommending a book published in 1999, when
Jet 4 had just been released, looks very unwise to me.

I don't really think you have any long-term significant experience
with replication. If you had that experience, you'd not be
recommending it for a WAN scenario without mentioning all the parts
of the process necessary to create a safe setup in that environment.

I've outlined some specifics about the pitfalls of replication in
these recent posts to this newsgroup (all on one line, of course):

http://groups-beta.google.com/group/comp.databases.ms-
access/msg/7ed5
9af7f5b16e8c

http://groups-beta.google.com/group/comp.databases.ms-
access/msg/8eaa
3d804bbbb4ee

If you're not scared of replication after reading those messages,
then you're much braver (or stupider) than *I* am.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #42

P: n/a
"John A. Mason" <ja*******@MYearthlink.net> wrote in
news:Jq***************@newsread3.news.atl.earthlin k.net:

So does anyone have any good Internet suggestions? Some way I
can either (a)
have one office use the back-end database off the other
computer (one office
has high speed Internet, it could be possible to get high-speed
Internet at
the second office as well) or (b) automatically update the
back-end database
over the Internet from one computer to the other besides for
using something
really manual like e-mail (this needs to be really
simple/automatic)?

Sounds like this would be a great time to use Replication.
If you aren't experienced with Replication, this is a very bad
idea.

I've recently outlined the details on this which you can read on
Google Groups (all on one line, of course):

http://groups-beta.google.com/group/comp.databases.ms- access/brows e_f rm/thread/86367765e66e1ee4


Don't we all start off 'inexperienced'? We live and learn. This is
simply a matter of knowing what tools are available to accomplish
the job correctly and then learning the tool. Please see my other
response for details.


I just posted a reply savaging your other reply. You aren't
supplying any of the caveats that point out the danger points with
replication.

Replication, if handled incorrectly, can lead to these kinds of
problems:

1. data edits transparently lost to conflicts.

2. data errors that prevent replicas from completely synchronizing
with each other, which means that your replicas will not have
identical data.

3. data errors that can eventually prevent your replicas from
synchronizing at all, and can cause data loss, in the worst case,
lost off *all* your data (not just recent edits).

4. corruption and complete loss of the Access project if you
erroneously choose to replicate the front end.

The mistakes that lead to these problems are VERY EASY TO MAKE.

With the exception of #4, I made ALL OF THEM in the process of
"starting off 'inexperienced' and gaining knowledge as I went along.
At the time, there was very little information about these kinds of
problems anywhere (Michael Kaplan was just starting to post the
results of his replication work, and
microsoft.public.access.replication was just getting a critical mass
of posts), and I was encoutering the same problems everyone else was
discovering.
I used Replication on a daily basis to connect 4 Access backends
over a LAN/WAN. The backends consisted of 87 tables and were about
25 mb in size. Over a LAN, the synchronizations were very quick...
on the order of seconds. Over the WAN (700 miles between sites,
for whatever that's worth), the replications took longer... on the
order of 3-5 minutes depending on conditions.
If you were using direct replication for this, then you had a big
pipe for it to take only 3-5 minutes.

If you were using indirect replication, then there are a lot of
details about how to accomplish it that you've not even alluded to
in any of your posts.
I cannot ever remember losing data to corruption. In the
environment this database was in (i.e. not real time/not everyone
writing to the same records at the same time), I infrequently had
synchronization conflicts... and those that occurred were easily
solved.


I don't really believe you. Your claims have no credibility. If you
were synching over a WAN in 3-5 minutes, then Replication Manager
was involved, along with all the setup issues on the local and
remote ends, with dropbox permissions and if you were using Internet
replication, all the IIS and FTP configuration issues. I don't for
one minute believe that you could do indirect or Internet
replication without running onto setup and reliability problems.

I *have* run replication setups in all kinds of scenarios (excluding
Internet replication, which I always considered unacceptable because
of the dependencies on IIS on both ends), and over the years, what
I've seen is that the setup is hard to configure and get up and
running in the first place, with significant remote administration
problems, and once running, *very* fragile and prone to failure
unless you constantly monitor and adjust the setup.

If you have run one 2-site setup over a WAN, then your experience is
not very broad. If you had no problems, then YOU WERE VERY, VERY
LUCKY.

I repeat: I no longer recommend replication for any scenario except
for laptops that need to edit data when out of the office. For
connecting fixed offices or remote users working, for example, in
home offices, Windows Terminal Server is vastly easier to administer
and far more reliable. It also brings with it absolutely no risks of
data loss or corruption that are not already present in a simple LAN
setup.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #43

P: n/a
"John A. Mason" <ja*******@MYearthlink.net> wrote in
news:JL***************@newsread1.news.atl.earthlin k.net:
<snip>

So does anyone have any good Internet suggestions? Some way I
can either (a)
have one office use the back-end database off the other
computer (one office
has high speed Internet, it could be possible to get high-speed
Internet at
the second office as well) or (b) automatically update the
back-end database
over the Internet from one computer to the other besides for
using something
really manual like e-mail (this needs to be really
simple/automatic)?

Sounds like this would be a great time to use Replication.


If you aren't experienced with Replication, this is a very bad
idea.

I've recently outlined the details on this which you can read on
Google Groups (all on one line, of course):

http://groups-beta.google.com/group/comp.databases.ms- access/brows e_f rm/thread/86367765e66e1ee4


I've read the thread in the Google groups you mention above. I'm
not sure I follow your advice here ('...bad idea'). You obviously
know Replication at least as well as I do. Have you *always* known
it this well? Of course not... you had to start somewhere and
learn it. The advice you gave to the poster on Google was
excellent and very useful for anyone needing/considering
Replication. Wouldn't a similar answer here, to the OP, be
appropriate? Thoughts?


No. The reason was that the scenario was too simple to make
replication a valid option. That is, the person implementing it did
not have the programming chops to implement the necessary version of
replication (Internet or indirect), nor the infrastructure. The
obvious easy choice was Windows Terminal Server, or, in this case,
where it was just two WinXP workstations at two different offices,
being used by a single person, Remote Desktop. That's a vastly
simpler setup than implementing replication and gives other benefits
unrelated to Access (such as being able to download your POP email
onto a single computer, regardless of which office you're in).

I think Jet replication has been made mostly obsolete for most
remote office setups by Windows Terminal Server. In my opionion, Jet
replication is only viable in scenarios where there is no Internet
connection available over which to run the application on WTS, or
where that is not practical (for expense reasons, for instance, if
the laptop user is mostly staying in hotels when out of the office,
and would have to pay for an expensive hotel Internet connection,
and would have to stay in the hotel to be able to edit the data).

And the beauty of replication with laptops is that the machines get
carried back into the office and are, presumably, connected to the
LAN there, and so you can use direct replication with no programming
whatsoever. *That* is truly easy to set up, though it does bring
with it the question of what data the user edits when in the office
(the LAN data or the laptop data), as well as the possibility of
human error in failing to synchronize at appropriate times. A bit of
judicious programming can take care of most of the problem with both
of these issues.

But the key point is this: the scenario involved here HAD NOTHING TO
DO WITH LAPTOPS. It was all about how to get to the same data from
two stationary PCs, each with an Internet connection. In that
scenario, replication is a layer of complexity that was simply not
needed, as WTS/RDP solves the problem with far less administrative
headache and not need for any programming at all, while also being
much safer (replication databases are more prone to corruption than
non-replicated databases).

The dangers of replication are greatest to the person inexperienced
with replication. And that's why I *always* recommend extreme
caution to anyone considering replication.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #44

P: n/a
Security is not black and white - there are degrees depending on the nature
of your data.

Your statement reflecting that all remote access should be done via VPN is
absurd. It does not even address that there are multiple levels of security
implementing VPN itself.

For some of my clients, remote access using Radmin, VNC, PcAnyWhere without
VPN is appropriate. For others, VPN (and not using the standard VPN
software included with Microsoft Windows 2003 Server) is only appropriate.
I don't treat a multi-billion dollar hedge fund the same way I treat a local
pest control company. But then, for the former type of client, I bring in
consultants who specialize in security.

My opinion is based on my experience. Yours may differ.
--
Steven R. Zuch, CPA
Principal

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.74...
"Steven Zuch" <st***@nospam.net> wrote in
news:Pd***********@fe08.lga:
But I find it limiting to state that you should never use remote
control software without a VPN.


Properly securing your network generally limits certain choices that
would open vulnerabilities on your network.

That's why it's called "security."

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc


Nov 13 '05 #45

P: n/a
<snip>
. . . As
with most things related to Access, there are increasing levels of
detail/difficulty. At it's core, Replication is very easy to
implement and use on a daily basis. Getting up and over the
learning curve yields great rewards.
YOU ARE SIMPLY WRONG.

NO DAVID.... *YOU* ARE WRONG.
If you're not scared of replication after reading those messages,
then you're much braver (or stupider) than *I* am.


David,
I find your condescending and judgmental responses very disturbing. I am
*not* wrong about what I have written. I do indeed agree with much of what
you say however; but you are making the issue much more 'scarier' than it
really is... perhaps you are trying to perpetuate an 'exclusive' club?

I do indeed respect your opinions... and I mentioned that your posts to the
Google group was very insightful and helpful. I was not *scared* after
reading them.... nor did it seem was the OP of that message. You helped
guide him and alert him to some issues, and he benefited from your advice.
Was it your *intent* to "scare"? If so, that is very sad of you. Again, did
you come into this world knowing all about Replication, or did you have to
learn it? Why deny others the opportunity to learn the same?

I have *extensive* experience using Access replication is a demanding
environment.... and I taught myself how to do it... using the sources I
mentioned (and others, including Kaplan's excellent information). Was it
easy? No. Was it impossible? No. Was it worth the effort? Absolutely.

Quit scaring people and start having faith in them and helping them.
Regards,
John
Nov 13 '05 #46

P: n/a
I just posted a reply savaging your other reply. You aren't
supplying any of the caveats that point out the danger points with
replication.

Replication, if handled incorrectly, can lead to these kinds of
problems:

1. data edits transparently lost to conflicts.

2. data errors that prevent replicas from completely synchronizing
with each other, which means that your replicas will not have
identical data.

3. data errors that can eventually prevent your replicas from
synchronizing at all, and can cause data loss, in the worst case,
lost off *all* your data (not just recent edits).

4. corruption and complete loss of the Access project if you
erroneously choose to replicate the front end.

The mistakes that lead to these problems are VERY EASY TO MAKE.
I agree... as are almost all of the areas of database development. It's not
inherently easy (that is, database application development).

With the exception of #4, I made ALL OF THEM in the process of
"starting off 'inexperienced' and gaining knowledge as I went along.
At the time, there was very little information about these kinds of
problems anywhere (Michael Kaplan was just starting to post the
results of his replication work, and
microsoft.public.access.replication was just getting a critical mass
of posts), and I was encoutering the same problems everyone else was
discovering.
Well, I'm glad you admit you made mistakes. I of course have made my share
of mistakes. However, I *did* learn Relication using the Online help and
mainly the FAQ and other sources from Microsoft. I only after learning the
basics found Kaplan's site. To be honest with you, it helped clarify a few
things, but wasn't critical to my environment. My experience with
Replication started with Access 2000 around 4 years ago. I have no
experience with it prior to that. I have had *extensive* experience with it
in those 4 years.
I used Replication on a daily basis to connect 4 Access backends
over a LAN/WAN. The backends consisted of 87 tables and were about
25 mb in size. Over a LAN, the synchronizations were very quick...
on the order of seconds. Over the WAN (700 miles between sites,
for whatever that's worth), the replications took longer... on the
order of 3-5 minutes depending on conditions.
If you were using direct replication for this, then you had a big
pipe for it to take only 3-5 minutes.

If you were using indirect replication, then there are a lot of
details about how to accomplish it that you've not even alluded to
in any of your posts.


I used Direct Synch only... and I never used the Synch Manager (I haven't
been able to get it to work with Access Security (since the database is
fully secured using Access User/Group security). It's an ongoing challenge.
For now, manually (directly) synchronizing the backends a couple of times a
day works well in the environment this application is being used for.
I cannot ever remember losing data to corruption. In the
environment this database was in (i.e. not real time/not everyone
writing to the same records at the same time), I infrequently had
synchronization conflicts... and those that occurred were easily
solved.


I don't really believe you. Your claims have no credibility. If you
were synching over a WAN in 3-5 minutes, then Replication Manager
was involved, along with all the setup issues on the local and
remote ends, with dropbox permissions and if you were using Internet
replication, all the IIS and FTP configuration issues. I don't for
one minute believe that you could do indirect or Internet
replication without running onto setup and reliability problems.

I'm sorry you don't believe me and I find your judgement of my credibility
to be really disturbing. You have no right to say that just because it
doesn't match with your experience. You are assuming I was doing indirect
replication... I am using Direct Syncronizations on demand as mentioned
above. Of course as you know the specific application Replication is used in
is very important. Maybe you don't have any experience using Replication in
the manner I've implemented it for our application.
I *have* run replication setups in all kinds of scenarios (excluding
Internet replication, which I always considered unacceptable because
of the dependencies on IIS on both ends), and over the years, what
I've seen is that the setup is hard to configure and get up and
running in the first place, with significant remote administration
problems, and once running, *very* fragile and prone to failure
unless you constantly monitor and adjust the setup.
I must defer to you here, since my experience is with Direct
Synchronizations only.
If you have run one 2-site setup over a WAN, then your experience is
not very broad. If you had no problems, then YOU WERE VERY, VERY
LUCKY.
I'm not sure if I was lucky or just really paid attention to the details
(and again, you must keep in mind my specific application of Replication).
I repeat: I no longer recommend replication for any scenario except
for laptops that need to edit data when out of the office. For
connecting fixed offices or remote users working, for example, in
home offices, Windows Terminal Server is vastly easier to administer
and far more reliable. It also brings with it absolutely no risks of
data loss or corruption that are not already present in a simple LAN
setup.


I respect your opinion. However, your experience is your experience. My
experience is my experience. Replication works well in the right
environment, for the right application, and assuming it is implemented
carefully with the appropriate and necessary attention to detail.
Regards,
John
Nov 13 '05 #47

P: n/a
>> I've read the thread in the Google groups you mention above. I'm
not sure I follow your advice here ('...bad idea'). You obviously
know Replication at least as well as I do. Have you *always* known
it this well? Of course not... you had to start somewhere and
learn it. The advice you gave to the poster on Google was
excellent and very useful for anyone needing/considering
Replication. Wouldn't a similar answer here, to the OP, be
appropriate? Thoughts?


No. The reason was that the scenario was too simple to make
replication a valid option. That is, the person implementing it did
not have the programming chops to implement the necessary version of
replication (Internet or indirect), nor the infrastructure. The
obvious easy choice was Windows Terminal Server, or, in this case,
where it was just two WinXP workstations at two different offices,
being used by a single person, Remote Desktop. That's a vastly
simpler setup than implementing replication and gives other benefits
unrelated to Access (such as being able to download your POP email
onto a single computer, regardless of which office you're in).

I think Jet replication has been made mostly obsolete for most
remote office setups by Windows Terminal Server. In my opionion, Jet
replication is only viable in scenarios where there is no Internet
connection available over which to run the application on WTS, or
where that is not practical (for expense reasons, for instance, if
the laptop user is mostly staying in hotels when out of the office,
and would have to pay for an expensive hotel Internet connection,
and would have to stay in the hotel to be able to edit the data).

And the beauty of replication with laptops is that the machines get
carried back into the office and are, presumably, connected to the
LAN there, and so you can use direct replication with no programming
whatsoever. *That* is truly easy to set up, though it does bring
with it the question of what data the user edits when in the office
(the LAN data or the laptop data), as well as the possibility of
human error in failing to synchronize at appropriate times. A bit of
judicious programming can take care of most of the problem with both
of these issues.

But the key point is this: the scenario involved here HAD NOTHING TO
DO WITH LAPTOPS. It was all about how to get to the same data from
two stationary PCs, each with an Internet connection. In that
scenario, replication is a layer of complexity that was simply not
needed, as WTS/RDP solves the problem with far less administrative
headache and not need for any programming at all, while also being
much safer (replication databases are more prone to corruption than
non-replicated databases).

The dangers of replication are greatest to the person inexperienced
with replication. And that's why I *always* recommend extreme
caution to anyone considering replication.

David,
Thanks for sharing your thoughts. I agree whole-heartedly with your last
paragraph. I just don't agree with dismissing it out-of-hand without any
consideration that we all have had to start somewhere.
Best,
John
Nov 13 '05 #48

P: n/a
"John A. Mason" <ja*******@MYearthlink.net> wrote in
news:LA****************@newsread1.news.atl.earthli nk.net:
my experience is with Direct
Synchronizations only.


Then you have NO BUSINESS whatsoever making recommendations about
the use of replication in a WAN environment.

If you're using direct replication over a WAN then you are very
lucky to not have lost data.

The lack of experience in anything but direct replication means that
you have simply not encountered the vast majority of problems
associated with replication.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #49

P: n/a
"Steven Zuch" <st***@nospam.net> wrote in
news:JL****************@fe10.lga:
Your statement reflecting that all remote access should be done
via VPN is absurd. It does not even address that there are
multiple levels of security implementing VPN itself.


Back when VPNs were hard and difficult and not really available in
consumer-level products, it might be an issue.

Nowadays, it's ridiculous to open up any ports on a server direct to
the Internet.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #50

56 Replies

This discussion thread is closed

Replies have been disabled for this discussion.