|
|
|
date: Sun, 27 Jul 2008 18:36:29 -0400,
group: microsoft.public.access.multiuser
back
Re: Testing two methods of remote access to an MS Access backend; Terminal Server and VPN
"barret bonden" wrote
> Tom:
>
> Thanks for the reply
>
> Would you suggest Terminal Server as a better alternative?
> I have read that with a back end/front end split I was
> safe, even with the interruptions to be found with off site access .
I believe you mis-read.
Splitting the back and front end just places your data somewhere other than
your own machine but still uses it just the same way it would use it if it
were in a folder on your local hard drive. That opens the opportunity that a
dropped connection (extremely common going over the Internet), even a
momentary one, can corrupt either the back-end database or your front-end
database. Access / Jet or Access/ ACE are file-server databases and all
the work is done on the machine where the front-end and database engine are
running.
If you want "safe" over a flakey network (which the public Internet is), you
will have to move your data to a server DB... MS SQL Server is one that many
use, but there are others, some free.
Or, alternatively, use Terminal Services in the manner it was intended, to
allow you to remotely execute your application ON THE SERVER -- not many
commercial web presence providers have such a capability, so this would very
likely have to be on your own web server machine (or a separate machine
hosted for you by a web presence provider).
Larry Linson
Microsoft Office Access MVP
date: Tue, 29 Jul 2008 19:40:26 -0500
author: Larry Linson
Re: Testing two methods of remote access to an MS Access backend; Terminal Server and VPN
Client-Server ( Access-SQL Server) normally works better
over a VPN than Access/MDB FE/BE, because over most WAN
or Internet most people consider Access/MDB FE/BE unusable.
However, I don't know anybody who has chosen to use
Access (ODBC) /SQL Server linked tables over the Internet
or over WAN when given the choice of Terminal Services:
TS has always run better. In fact, if the client is in management
and TS is not an option, a local, secret, off-the-record server
is the choice when SQL Server is supposed to be located at
the off-site IT support facility.
But I know that people read high-resolution X-Rays off-shore
(to take advantage of time-zone differences) so some people
do really have high speed Wide Area Networks: If your
network is fast enough and good enough, it doesn't matter.
(david)
"sctech via AccessMonster.com" <u44987@uwe> wrote in message
news:880765c97374b@uwe...
> So assuming that one would want to set up a front and back end system
> where
> the front end mdb is located at point A and the back end at point B. Where
> the internet is used as the pipeline of interconnection, what would be the
> best way to set this up? FTP site (mapped), VPN, TS? Assuming that you
> convert to a Client Server set up still using MS ACCESS would this help?
>
> david wrote:
>>Many people find that a VPN is too slow, much slower than Terminal
>>Services. What kind of a network is the VPN running over?
>>
>>Personally, I've never had a client that used a VPN given any choice. I
>>have used Access over a VPN for interstate support where I was
>>willing to wait 5-10 minutes for a form to open: I've seen low-wage staff
>>using the same application with 1 minute form open times because they
>>were given no choice. (That was many years ago) It was less bad than
>>trying to use an Access application running with Anti-Virus scanning
>>across the local network, which gave 20-30 minute form open times.
>>
>>(david)
>>
>>> Testing two methods of remote access to an MS Access backend; Terminal
>>> Server and VPN. So far VPN is ahead. Using Cisco Easy VPN client I get
>>> an
>>[quoted text clipped - 8 lines]
>>>
>>> Are there any "gotcha's" awaiting me ?
>
> --
> Message posted via http://www.accessmonster.com
>
date: Tue, 5 Aug 2008 11:14:05 +1000
author: david
|
|
