Re: Access to ASP/VB.net converters

"robert d via AccessMonster.com" <u6836@uwe> wrote in
5a3a524d21816@uwe:">news:5a3a524d21816@uwe:

> Not sure yet. I haven't made the pitch yet, but I just have the
> feeling that there consultant is pushing a totally web-based
> solution.

Sounds to me like a straight cost/benefit analysis ought to take
care of it. Setting up a Terminal Server is comparatively easy and
inexpensive (though there are a few little gotchas, like the license
server problems). Rewriting an existing app as a browser-based
application and setting up ASP hosting (which depends on the
incredibly insecure IIS) is going to cost far, far more than
implementing a brand-new Terminal Server, and you're going to lose
functionality and ease of use for very little gain in the way of
administrative centralization and client independence.

> There network solutions are slow, so, correct me if I'm wrong, but
> wouldn't a terminal services solution where the Access front end
> and the SQL Server backend are located on the same server provide
> relatively fast response. . . .

As long as the connection is not so slow that it causes lags in
terminal window response. Given that Remote Desktop works usably
over dialup, that would have to be an extremely slow network
connection.

> . . . Do
> you think it would be faster than an ASP front end?

That's not really a comparable question. A properly designed ASP
front end will be as responsive as any browser-based application,
but all browser-based applications have limitations in comparison to
desktop apps because:

1. the widgets are much more primitive and the events much less
plentiful, AND

2. web apps are stateless. That is, all web apps are basically like
unbound forms in Access.

Both of these have enormous repercussions for user interface design.
You can't just port your Access screens directly to an ASP app --
almost all processes have to be redesigned from scratch to work the
way browser-based apps work.

This kind of thing is very difficult for someone who is accustomed
to programming in Access. I still have major problems designing
browser-based interfaces (I use PHP), because I have to abandon all
my Access-developed instincts for how to model processes and
implement user interaction.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.

Relevant Pages

  • Re: adding a terminal server
    ... you will need the applications residing on the terminal server. ... I'm assuming the apps ... be a backstep to run apps and all local users and remote users. ...
    (microsoft.public.windows.terminal_services)
  • Access 97 RunTime & Terminal Services
    ... We have numerous Access 97 apps that we run on our Terminal Server, ...
    (comp.databases.ms-access)
  • Re: Access 97 RunTime & Terminal Services
    ... and when logged on the server locally. ... If I run the apps on my workstation they work fine. ... not being able to connect to the SQL Server. ... but not on the deployed Terminal server. ...
    (comp.databases.ms-access)
  • Re: Access 97 RunTime & Terminal Services
    ... but two apps in particular is giving us a problem. ... and when logged on the server locally. ... not being able to connect to the SQL Server. ... but not on the deployed Terminal server. ...
    (comp.databases.ms-access)
  • Re: Access 97 RunTime & Terminal Services
    ... but two apps in particular is giving us a problem. ... and when logged on the server locally. ... not being able to connect to the SQL Server. ... but not on the deployed Terminal server. ...
    (comp.databases.ms-access)