Access and Sharepoint

  • Thread starter Thread starter Tony Williams
  • Start date Start date
T

Tony Williams

I have a database built in Access 2003 which is split between a backend and a
front end. We have used this over a vpn without any problems, the front end
files on each local machine and the back end on a remote server. Our IT
service has now moved us to Sharepoint and have told us that we cannot use
Access with split files using Sharepoint and have had to leave the database
on the vpn network. They say it just can't be done. Is this correct? I know
nothing about Sharepoint so I cannot challenge them but it seems that the
problem lies in the Sharepoint connection uses an internet connection rather
than a vpn connection.
Thanks
Tony
 
=?Utf-8?B?VG9ueSBXaWxsaWFtcw==?= <Tony
(e-mail address removed)> wrote in
I have a database built in Access 2003 which is split between a
backend and a front end. We have used this over a vpn without any
problems, the front end files on each local machine and the back
end on a remote server. Our IT service has now moved us to
Sharepoint and have told us that we cannot use Access with split
files using Sharepoint and have had to leave the database on the
vpn network. They say it just can't be done. Is this correct? I
know nothing about Sharepoint so I cannot challenge them but it
seems that the problem lies in the Sharepoint connection uses an
internet connection rather than a vpn connection.
Click to expand...

I'm rather confused by your description. A VPN is usually used to
provide a secure tunnel across the Internet, and is almost always
completely unsuitable to an Access app with front end on your local
PC having linked tables to a back end that's on the other end of the
VPN tunnel -- there just isn't enough bandwidth to allow the Access
app to be responsive (unless it has been extremely carefully written
just for that environment).

Sharepoint is an HTTP service, and whether or not it requires a VPN
to connect to it depends on whether the Sharepoint server is facing
outward to the Internet, or is inside a firewall.

I would not want any of my Access apps with Jet back ends to be
unilaterally converted to a Sharepoint back end, as Sharepoint lacks
any enforcment of referential integrity.

Who has made this decision and did they consult with you about it?

I would say that the best solution that comes to mind is to move
your Access/Jet application (without Sharepoint at all) to a Windows
Terminal Server, and have your users run it on the Terminal Server
via Remote Desktop.
 
Thanks David. It may be that I had my terminology incorrect. We had a the
back end on a remote server operated by an IT service with remote login and
the front end worked from the local harddrives. It worked fine and we didn't
have any problems apart from when the connection went down! The IT services
compnay have trasnferred all there services to us from this method where we
dialled in to their server over to Sharepoint and they are saying that Access
wont work in a Sharepoint environment yet Microsoft say the opposite on their
Sharepoint site. I was wondering what would be the best approach, move to
Sharepoint or leave the Access application on the dialup facility.
Thanks again
Tony
 
I am not personally aware of any "split Access application" with Jet or
ACCDB backend on a server, and front end on a local computer that provided
even minimally acceptable performance over dialup. I have known of some
Access client applications working over a slow WAN (256K leased line) that
provided _minimally_ acceptable performance with a server (Informix) DB
backend (but the users all cheered and celebrated when the leased line was
upgraded to T-1, 1.5 Mbps).

If you have something that works for you, and you can "leave it alone" so it
still works for you, then that is exactly what I would do. Unless others
are accessing your data directly via SharePoint, there is no advantage to
your storing it there (in fact, people report that performance is likely to
be much worse), and, as David said, SharePoint tables have no support for
referential integrity. In their current implementation, my guess would be
that most uses of "Access with SharePoint" are to maintain and manipulate
data, then upload it to SharePoint for other users to access (read-only)
directly.

Larry Linson
Microsoft Office Access MVP
 
=?Utf-8?B?VG9ueSBXaWxsaWFtcw==?=
It may be that I had my terminology incorrect. We had a the
back end on a remote server operated by an IT service with remote
login and the front end worked from the local harddrives.
Click to expand...

That's precisely the scenario I described, and I strongly doubt it's
what you actually, unless you're one of the lucky few who has a
gigabit-level WAN.
It worked fine and we didn't
have any problems apart from when the connection went down! The IT
services compnay have trasnferred all there services to us from
this method where we dialled in to their server over to Sharepoint
and they are saying that Access wont work in a Sharepoint
environment yet Microsoft say the opposite on their Sharepoint
site. I was wondering what would be the best approach, move to
Sharepoint or leave the Access application on the dialup facility.
Click to expand...

"Dial in" suggests to me that you were likely running the whole
thing remotely on their server. As Larry Linson says, there is no
way any Access app with front end on the local PC and back end
across a dialin wire could ever work fast enough to be at all
usable. Using Remote Desktop to a Terminal Server, on the other
hand, can work very well in that situation.

I think you need to dump your provider, as so far as I can tell from
what you're telling us, they are screwing you over. And not being
forthcoming at all.
 
Back
Top