Maintenance over FTP

[Ben]

Hi All,

I was wondering whether it is safe to download the back end of a database,
compress it on my machine and upload it again over the ftp?
Is this risky?

THanks

 

[Douglas J. Steele]

There should be no problem. It's certainly better than trying to compact
over the wire (which would require that you be able to get to a share on the
server: you can't do it using FTP)

 

[Ben]

Thanks for this. I also have VPN connection but I'm afraid that it might
crash because of the speed issue with my vpn connection. I'll try it this
night or another night when no users are in the DB.

I have another problem:
When trying to get into the database over VPN, it doesn't find the back end.
Are there any special settings for VPN use or Does the VPN tunnel connection
need to get the same name as the server.
Example: Drive is called \\Server and over VPN it has the IP address instead
of server.
THis allows me to open the front end and to log in but it doesn't allow me
to view any data.

Thanks again

 

[Scott McDaniel]

Thanks for this. I also have VPN connection but I'm afraid that it might
crash because of the speed issue with my vpn connection. I'll try it this
night or another night when no users are in the DB.

I have another problem:
When trying to get into the database over VPN, it doesn't find the back end.
Are there any special settings for VPN use or Does the VPN tunnel connection
need to get the same name as the server.

No, but the VPN does need to be able to get to the right location, and VPN users must have the necessary permissions on
the server's folder (read/write/create/execute). I'd assume you're using the same login as you would use on the LAN, so
that point is probably moot.

When you connect via VPN, you basically use it as you would any network resource ... so after connecting, can you browse
the server's folders and such? If you can, then your VPN is connected, and at that point I'd look into permissions.

I use a VPN occasionally to grab a file from a remote client, but I long ago gave up trying to actually open the
database across a WAN. In most cases, the database would simply not connect (or the connect time was soooo long that I
just gave up), but in some cases the backend would corrupt.

Example: Drive is called \\Server and over VPN it has the IP address instead
of server.
THis allows me to open the front end and to log in but it doesn't allow me
to view any data.

I'm assuming you're opening a LOCAL frontend, and you're trying to view data that stored on the server, and you're
trying to do this over the VPN? If so, read my comments above ... but if you still want to do this, then relink your
local frontend to the backend on the VPN ... you can do this with the Linked TAble Manager(Tools - Database Utilities)
in Access, just follow the prompts and make sure to check the "Always Prompt for New Location" checkbox.


Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

 

[Ben]

Yes, you assume correct. I do use local front end and Server based backend.
VPN is running ok and permissions, I have administrator permission so this
shouldn't be a problem.

I will try the Linked table manager suggestion but I think you're right
about the speed problem. Would probably be too frustrating.

I am looking into adding some online features as soon as they start using a
webserver but I guess I'll come back with questions about that later.
There are only a certain features of the database that need to be visible
for remote workers. Most of them not even editable so I guess this could
easily be made.

Thanks for your help and clear explanations.

 

[Arvin Meyer [MVP]]

I use Terminal Services over a VPN extensively for database maintenance. One
word of caution, always make a backup copy of the database first. I've never
had a problem with terminal services, but there is always a remote chance.

Also, I don't run a copy of Office or Access on the server, so it is
impossible to connect in and compact from there. What I do is to connect to
the server first, then use that machine to connect to one of the
workstations on the system. I then do the maintenance from the workstation.

 

[David W. Fenton]

I use Terminal Services over a VPN extensively for database
maintenance. One word of caution, always make a backup copy of the
database first. I've never had a problem with terminal services,
but there is always a remote chance.

Huh? A disconnect won't cause problems as nothing has been shipped
across the wire. Depending on the settings on your Terminal Server,
you should be able to reconnect and resume with the existing
session.

Also, I don't run a copy of Office or Access on the server, so it
is impossible to connect in and compact from there. What I do is
to connect to the server first, then use that machine to connect
to one of the workstations on the system. I then do the
maintenance from the workstation.

I don't think this makes any sense. If you're on a VPN, why not just
connect directly to the workstation?

I also don't see any issue with installing Office/Access on a
server.

(but I believe I recall having this discussion before -- it's
summer, so we're in reruns!)

 

[Arvin Meyer [MVP]]

Huh? A disconnect won't cause problems as nothing has been shipped
across the wire. Depending on the settings on your Terminal Server,
you should be able to reconnect and resume with the existing
session.

Not directly, but if working from a workstation to the server it may. Like
I've said though, I haven't had a problem yet.

I don't think this makes any sense. If you're on a VPN, why not just
connect directly to the workstation?

That could easily be done if the workstation had a fixed IP. When using DHCP
for the workstations, it can be difficult to connect to a workstation from
outside. It's a piece of cake with the server and a fixed IP address.

I also don't see any issue with installing Office/Access on a
server.

(but I believe I recall having this discussion before -- it's
summer, so we're in reruns!)

< sure enough, grin>

Some admins won't allow running application executables on a server. But the
biggest reason I know of is that it uses an Office license unnecessarily.

 

[David W. Fenton]

Not directly, but if working from a workstation to the server it
may. Like I've said though, I haven't had a problem yet.

Hmm. I think it would depend on the settings on the individual
machines you're connected to. That is, if the workstation is set to
close the session when the connection is dropped, that will also
close the server session. If it's not, it won't.

I've worked in both situations and vastly prefer a server *not*
closing the session when a connection is dropped.

But, I don't always have control over that setting.

That could easily be done if the workstation had a fixed IP. When
using DHCP for the workstations, it can be difficult to connect to
a workstation from outside. It's a piece of cake with the server
and a fixed IP address.

But you don't need an IP address unless your network has NetBIOS
over TCP/IP turned off. Once you connect to the VPN, it's the same
as being on the local LAN, so you should be able to access the
workstation by name unless, as I said, NetBIOS over TCP/IP is
disabled.

< sure enough, grin>

Some admins won't allow running application executables on a
server. But the biggest reason I know of is that it uses an Office
license unnecessarily.

Hmm. Most of the clients I'm doing this with have Open License
programs, and have plenty of Office licenses available, so it's
never been an issue. A couple of them that I only use very
infrequently just install Office without registration. In both
instances of this, over two years or so, I've still not used up the
50 trial runs (or whatever the number is).

I don't see how a server that is a Terminal Server is helped by
disallowing the installation of Office. Indeed, I'd think that the
licensing involved would be based on the TS CALs and the client's
Office license, not on what's installed on the Terminal Server
itself.

 

[Arvin Meyer [MVP]]

Of the 4 remote installations that I currently support:
1. Large public corporation - does not allow Office on server. I have
admin rights on a test server where I may VPN and use terminal services.
When I'm done the local admin on site moves the databases to the production
server. Office does not run on the server.
2. Small office - 10 machines, 10 licences (2 - 5 packs) Office does not
run on the server.
3. Small office - 3 machines, 5 licenses (1 - 5 pack) Office runs on
the server

None of these run Terminal Server, all run terminal services and I log in as
admin.

4. Large Fortune 100 corporation - Terminal Server - Office is running
on the server.

Numbers 2 and 3 are SBS servers one has a fixed IP address, the other
doesn't. NetBIOS only runs on 3. Before #4 was purchased, my connection was
to a local machine with a fixed IP address, where I had access to
everything. After that corporation was purchased by the larger one, I was
only permitted an account on the Terminal Server.

Terminal Servers require an installation of Office to run Office programs.
Terminal services can be run from anywhere. I believe that Office 2007
requires that an Open license of the Enterprise edition be used for the
Terminal Server, as it won't run any other way. If that is true, the only
other way to connect and run Office would be through a workstation.

So you see that there are all sorts of situations. If the public IP address
is not fixed, I must connect to the server to get in, then to another
another machine if Access is not installed on the server.

 

[David W. Fenton]

Of the 4 remote installations that I currently support:
1. Large public corporation - does not allow Office on server.
I have
admin rights on a test server where I may VPN and use terminal
services. When I'm done the local admin on site moves the
databases to the production server. Office does not run on the
server.
2. Small office - 10 machines, 10 licences (2 - 5 packs)
Office does not
run on the server.
3. Small office - 3 machines, 5 licenses (1 - 5 pack) Office
runs on
the server

None of these run Terminal Server, all run terminal services and I
log in as admin.

Of *course* they're running TS or you couldn't log in remotely! The
question is what licenses are used for the login, and you're likely
using the two built-in admin CALs. But since you've got Access
installed on the computer you're using to connect to the server, you
have sufficient licenses to run Access on the server.

I don't see the issue!

4. Large Fortune 100 corporation - Terminal Server - Office is
running
on the server.

Numbers 2 and 3 are SBS servers one has a fixed IP address, the
other doesn't. NetBIOS only runs on 3. Before #4 was purchased, my
connection was to a local machine with a fixed IP address, where I
had access to everything. After that corporation was purchased by
the larger one, I was only permitted an account on the Terminal
Server.

Terminal Servers require an installation of Office to run Office
programs. Terminal services can be run from anywhere. I believe
that Office 2007 requires that an Open license of the Enterprise
edition be used for the Terminal Server, as it won't run any other
way.

That's true -- a terrible thing, in my opinion, but fairly
predictable when you think about it.

If that is true, the only
other way to connect and run Office would be through a
workstation.

The Enterprise licensing wasn't as expensive as I feared the last
time I looked at it.

So you see that there are all sorts of situations. If the public
IP address is not fixed,

And NetBIOS disabled...

I must connect to the server to get in, then to another
another machine if Access is not installed on the server.

Networks that disable NetBIOS are well-run, and I don't see many of
those!

 

[Tom Wickerqueer]

you don't

SQL Server supports FTP and remote connections

Access MDB does not

get with the times, kid