"David W. Fenton" wrote in message

Writing an Access app to run on SQL
Server across the Internet means you have to really understand how
to design and maintain server-side components (view and stored
procedures) and then you have to carefully design your app to use
those server-side objects, and you may have to jump through certain
hoops (such as using ADO to get editable results from sprocs) that
are not compatible with default Access behaviors/designs.

I very much agree with your assessment.

As a general rule due to having good skills with SQL server, then the issue
of learning curve and converting an application to run correctly over a WAN
or internet using SQL server is an easy task for me. (so, then sql becomes a
cheaper setup).

Comparing the learning curve of SQL server to a one time setup of terminal
services as you state, I think the terminal services suggestion on your part
wins hands down.


There really is no comparison in regard to the cost and difficulty
level.

Cost for me using sql server is less. I have many successful applications
running over the Internet using SQL server. However, I done the learning
curve. We don't even used stored procedures. We use some pass-through, and
mostly link to views for joins on reports or pick lists. I can zero in and
get a access application up and running for SQL server in a WAN environment
in VERY little time now. I am also using a hosted option for sql server.
And, sql Azure can be had for $10 a month for a 1 gig database. I believe
the trials are on now, and I can't wait to try Azure.

However, WTS vs SQL server in BOTH cases, a server + VPN must be setup.

WTS really is far less learning overall. And, one does NOT spend money
modifying an already good working access application.

So, the larger and more complex the access application, the the more work
needed for SQL server. This thus again favors he WTS choice.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada