Access performance on the Web vs TS

[Bob Darlington]

It has been suggested to me (by a potential client) that my app (which he is
considering buying) should be web enabled to improve performance,
particularly regarding screen refreshes.

My initial reaction was to say "No' (I was cringing at the time), 'cos I
just don't want to do it. But after a reality check, I thought that I should
consult the experts, so here I am.

Is there any reason to expect my access 2002 application to run any faster
if web enabled than over the current TS / VPN on a Windows 2003 server?
The max number of users is 40 with no more than 20 concurrent. It is not a
heavy data entry app, more a matter of frequent edits and updates.
Users only need to access the app from established offices with broadband
connections, so unlimited remote capabilities are not really an issue.
Would the answer to the above question be any different if I introduced
links to additional graphics (eg floor plans) and graphs to the application?

--
Bob Darlington
Brisbane

[Steve Jorgensen]

There will probably be a noticeable speed increase using a Web form client vs
using a remote terminal server connection. On the other hand, Web enableing
isn't something you do to an Access application, it's a new application you
write using the old Access application as a prototype.

If you do decide it is worth a very big development investment to make the
application run better over a WAN, there are other options besides a browser
form based application that you should look into. It might cost less to
implement a 2-tier application using something like DCOM or Java RMI, so you
don't have to try to force-fit your UI into something that works well with a
browser. If you want, you can make your front-end components launchable and
updateable via the browser by writing them as ActiveX controls or Java
Applets.

On Mon, 2 May 2005 12:41:11 +1000, "Bob Darlington" <bo*@dpcmanAX.com.au>
wrote:

It has been suggested to me (by a potential client) that my app (which he is
considering buying) should be web enabled to improve performance,
particularly regarding screen refreshes.

My initial reaction was to say "No' (I was cringing at the time), 'cos I
just don't want to do it. But after a reality check, I thought that I should
consult the experts, so here I am.

Is there any reason to expect my access 2002 application to run any faster
if web enabled than over the current TS / VPN on a Windows 2003 server?
The max number of users is 40 with no more than 20 concurrent. It is not a
heavy data entry app, more a matter of frequent edits and updates.
Users only need to access the app from established offices with broadband
connections, so unlimited remote capabilities are not really an issue.
Would the answer to the above question be any different if I introduced
links to additional graphics (eg floor plans) and graphs to the application?

[EnieMeanieMinieMo]

"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in message
news:42**********************@news.optusnet.com.au ...

It has been suggested to me (by a potential client) that my app (which he
is considering buying) should be web enabled to improve performance,
particularly regarding screen refreshes.

My initial reaction was to say "No' (I was cringing at the time), 'cos I
just don't want to do it. But after a reality check, I thought that I
should consult the experts, so here I am.

Is there any reason to expect my access 2002 application to run any faster
if web enabled than over the current TS / VPN on a Windows 2003 server?
The max number of users is 40 with no more than 20 concurrent. It is not a
heavy data entry app, more a matter of frequent edits and updates.
Users only need to access the app from established offices with broadband
connections, so unlimited remote capabilities are not really an issue.
Would the answer to the above question be any different if I introduced
links to additional graphics (eg floor plans) and graphs to the
application?

--
Bob Darlington
Brisbane

Steve is stupid. Disregard his post.

TS out performs any Web-based application 4 to 1.

You don't need to rewrite your Access application for Web deployment.
Simply use Terminal Services Advanced Client.

[Steve Jorgensen]

On Sun, 1 May 2005 21:48:03 -0600, "EnieMeanieMinieMo" <no****@nospam.net>
wrote:

"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in message
news:42**********************@news.optusnet.com.a u...

It has been suggested to me (by a potential client) that my app (which he
is considering buying) should be web enabled to improve performance,
particularly regarding screen refreshes.

My initial reaction was to say "No' (I was cringing at the time), 'cos I
just don't want to do it. But after a reality check, I thought that I
should consult the experts, so here I am.

Is there any reason to expect my access 2002 application to run any faster
if web enabled than over the current TS / VPN on a Windows 2003 server?
The max number of users is 40 with no more than 20 concurrent. It is not a
heavy data entry app, more a matter of frequent edits and updates.
Users only need to access the app from established offices with broadband
connections, so unlimited remote capabilities are not really an issue.
Would the answer to the above question be any different if I introduced
links to additional graphics (eg floor plans) and graphs to the
application?

--
Bob Darlington
Brisbane
Steve is stupid. Disregard his post.

Excuse me, but I've done hands-on testing with various kinds of TS clients,
and there is a latency in response to keystrokes and menu clicks that can
really impede usability. This problem is particularly pronounced if you have,
say, Satellite internet users where, although the speed is fine, the
round-trip latencies can be well over 1/2 a second. On the other side of the
coin, if you have dial-up modem users, the latency may be fine, but the speed
is too slow when large blocks of the screen must be redrawn.

For these same users who have a performance problem with TS, both the latency
and speed issues only apply when a form is posted and a page retrieved. The
data set being sent for a Web page is a small fraction of the size of a TS
screen update, and since data is not going back and forth for every keypress,
the latency is not much of a problem.
TS out performs any Web-based application 4 to 1.
As I've poitned out above - that's total hogwash. That is, unless you've seen
a lot of really poorly written Web applications.
You don't need to rewrite your Access application for Web deployment.
Simply use Terminal Services Advanced Client.

I normally recommend that, too. From the language of the original post,
though, I understand that TS is being used right now and is being perceived as
too slow. Since I've seen other cases where that is the case, I have no
reason to doubt the veracity of the statement.

[billmiami2]

Bob,

In many cases, I've noticed a significant improvement in performance
when using a web interface with a MS Jet database over a standard MS
Access interface with linked tables. The improvement was most dramatic
in the time it took to initially load forms. In some cases where the
Access application to several seconds to open a complex form with many
subforms, the comparable form in the web application opened almost
instantaneously. However, this could be because I did a much better
job designing the web interface than I did the Access interface.
Perhaps if I used unbound forms in the Access app, I would have had
comparable load times.

Once the form was opened in the Access application, I can't really say
which was faster. In a way, the web application could be slower from a
"refresh" standpoint because the entire page is refreshing on each
postback.

As Steve said, creating a web application is a complete redesign so
it's not to be taken lightly. On the other hand, if it significantly
improves customer acceptance of your application (for the right or
wrong reasons) then you should certainly consider creating one.

Bill E.

[EnieMeanieMinieMo]

<bi********@netscape.net> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...

Bob,

In many cases, I've noticed a significant improvement in performance
when using a web interface with a MS Jet database over a standard MS
Access interface with linked tables. The improvement was most dramatic
in the time it took to initially load forms. In some cases where the
Access application to several seconds to open a complex form with many
subforms, the comparable form in the web application opened almost
instantaneously. However, this could be because I did a much better
job designing the web interface than I did the Access interface.
Perhaps if I used unbound forms in the Access app, I would have had
comparable load times.

Once the form was opened in the Access application, I can't really say
which was faster. In a way, the web application could be slower from a
"refresh" standpoint because the entire page is refreshing on each
postback.

As Steve said, creating a web application is a complete redesign so
it's not to be taken lightly. On the other hand, if it significantly
improves customer acceptance of your application (for the right or
wrong reasons) then you should certainly consider creating one.

Bill E.

MS Jet on the Web? Unbound forms? You ought to have your butcher's license
revoked.

[David W. Fenton]

"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in
news:42**********************@news.optusnet.com.au :

Is there any reason to expect my access 2002 application to run
any faster if web enabled than over the current TS / VPN on a
Windows 2003 server?

Details don't actually matter.

There won't be any increase in speed. There may, in fact, be a
decrease in speed, because of increased latency between the web
browser and the server back end. When they are using terminal
server, there is no latency except for the *display* of the results
of tasks, and I've found that to be very little with reasonable
consumer-level Internet connections. Indeed, last week I did four
hours of heavy-duty program on a client's application, all in a
Terminal Server session. It was not quite as snappy as local, but it
was certainly very easy.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:0t********************************@4ax.com:

From the language of the original post,
though, I understand that TS is being used right now and is being
perceived as too slow.

Then they probably need better Internet connections.

Dialup can be vastly improved with the Citrix Metaframe extensions,
I understand, but it's still going to be slower than broadband.

But I've got clients on 384K DSL connections and when they connect
to the home office's T1, they can work just fine with latency that
is slight enough to not be problematic at all.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

bi********@netscape.net wrote in
news:11*********************@o13g2000cwo.googlegro ups.com:

In many cases, I've noticed a significant improvement in
performance when using a web interface with a MS Jet database over
a standard MS Access interface with linked tables. The
improvement was most dramatic in the time it took to initially
load forms. In some cases where the Access application to several
seconds to open a complex form with many subforms, the comparable
form in the web application opened almost instantaneously.
Well, that would be because the form WAS NOT REALLY COMPARABLE.

You cannot replicate the functionality of an Access form of any
complexity in a web browser. It's simply impossible.
However, this could be because I did a much better job designing
the web interface than I did the Access interface. Perhaps if I
used unbound forms in the Access app, I would have had comparable
load times.
The web-based "form" could not possibly have been as sophisticated
as the Access form.

And if the Access form was slow to load, then you probably hadn't
designed it very well. You don't need to go with unbound forms to
get efficiency in an Access form -- all you have to do is reduce the
dataset loaded to that which is necessary for the user's task, and
no more. Many sloppy Access programmers load entire tables behind
forms, and put huge tables in combo boxes and subforms (100s or
1,000s of records). That's just poor design, the kind of thing you
can't get away with in a web application.
Once the form was opened in the Access application, I can't really
say which was faster. In a way, the web application could be
slower from a "refresh" standpoint because the entire page is
refreshing on each postback.
Well, D'oh!
As Steve said, creating a web application is a complete redesign
so it's not to be taken lightly. On the other hand, if it
significantly improves customer acceptance of your application
(for the right or wrong reasons) then you should certainly
consider creating one.

It would probably be a lot cheaper to give the Terminal Server users
fatter pipes than it would be to completely re-engineer the app to
run in a web browser. And you wouldn't be sacrificing functionality,
as you would compared to the Access app.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Bob Darlington]

Thanks David,
I guess that is what I was hoping to hear.
As far as I am concerned, TS is fine. The screen refreshes are as fast as my
LAN. But I needed to address the question as raised by the client (who
doesn't yet have the app).

I should not have used the term 'enabled' in my original post. I'm aware
from the many postings to this group that a complete new project would be
required.

I gather then, that the only real advantage of going to the web, would be
the benefits of being able to connect from anywhere. Is that your
understanding?

--
Bob Darlington
Brisbane
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86...

"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in
news:42**********************@news.optusnet.com.au :

Is there any reason to expect my access 2002 application to run
any faster if web enabled than over the current TS / VPN on a
Windows 2003 server?

Details don't actually matter.

There won't be any increase in speed. There may, in fact, be a
decrease in speed, because of increased latency between the web
browser and the server back end. When they are using terminal
server, there is no latency except for the *display* of the results
of tasks, and I've found that to be very little with reasonable
consumer-level Internet connections. Indeed, last week I did four
hours of heavy-duty program on a client's application, all in a
Terminal Server session. It was not quite as snappy as local, but it
was certainly very easy.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve Jorgensen]

On Tue, 03 May 2005 05:37:17 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:0t********************************@4ax.com :

From the language of the original post,
though, I understand that TS is being used right now and is being
perceived as too slow.
Then they probably need better Internet connections.

In a sense, that's true, but you live in NY. Here in Oregon, some companies
have remote offices and work-at-home employees in locations that normal
broadband options don't yet reach. These workers generally have to choose
between dial-up that's too slow and satellite with too high a latency.
Dialup can be vastly improved with the Citrix Metaframe extensions,
I understand, but it's still going to be slower than broadband.

But I've got clients on 384K DSL connections and when they connect
to the home office's T1, they can work just fine with latency that
is slight enough to not be problematic at all.

384K DSL is fine for TS - great even. Dial-up latencies on a good ISP are
adequate too (just barely), it's just the total throughput that's a problem.
For some apps, TS is OK on dial-up, and for others it isn't.

[Trevor Best]

Bob Darlington wrote:

Thanks David,
I guess that is what I was hoping to hear.
As far as I am concerned, TS is fine. The screen refreshes are as fast as my
LAN. But I needed to address the question as raised by the client (who
doesn't yet have the app).

Also note what David alluded to in another post, the web page will not
be as functionally rich as an Access form. You have to realise also that
potential clients are potential users, and users can be a bit dim when
it comes to kom-poo'ers. For example, I regularly have to demonstrate an
Access front end over the internet, the potential client terminals in
via TS and is shown and can interact with the app. Then they go and ask
such questions as "is it web enabled?" when told no he then asks how
would a remote office use the application. Mute phone, let out big sigh.

[Lyle Fairfield]

Trevor Best wrote:

Bob Darlington wrote:

Thanks David,
I guess that is what I was hoping to hear.
As far as I am concerned, TS is fine. The screen refreshes are as fast
as my LAN. But I needed to address the question as raised by the
client (who doesn't yet have the app).
Also note what David alluded to in another post, the web page will not
be as functionally rich as an Access form.

Could you explain which features of an Access form are not replicable in
html (written by ASP or whatever)?

What about interfacely rich? Could the use of CSS create an HTML form
that might be richer in terms of alignment, hovers, text-decoration,
font-variant, margins, padding etc etc etc than an Access form?
You have to realise also that
potential clients are potential users, and users can be a bit dim when
it comes to kom-poo'ers. For example, I regularly have to demonstrate an
Access front end over the internet, the potential client terminals in
via TS and is shown and can interact with the app. Then they go and ask
such questions as "is it web enabled?" when told no he then asks how
would a remote office use the application. Mute phone, let out big sigh.

(Sequence is important here. I once got into some difficulty by
interchanging [Mute Phone] and [What a bitch!] in the order of things.)

Regardless, do the clients/users ask, "Well, if there are 25
simultaneous users how many CPU's are doing (most of) the work?" If they
did, what's the answer?

If there are 25 users are they all running the same application file on
the same machine? Or do they (somehow) run their own copy of the
application which hooks up with the db via TS?

How do TS applications fit with the idea of separation of data, business
logic and interface?

How do TS applications whose db is MS-SQL compare with ADPs in terms of
speed?

How do TS applications compare with DAPs in terms of speed?

I've used TS very minimally, and that only to maintain one dedicated web
server and a dedicated MS-SQL server, and that a few years ago.

But I've written quite a bit in HTML and ASP lately (most recent example
is in my sig line). It seems these are unsuited to continuous forms of
thousands of records, but no more so than any other unbound form, Access
or otherwise. ADO and UpDateBatch make continuous forms of a smaller
number of records very easy to manage from a database point of view.
Open the recordset that was the original source of the form's data. Scan
the form elements; find those identified as each record is identified;
compare the form's values with the recordset's values; change the
recordset's values where they are not the same. Set the filter to
adFilterPendingRecords. (<-This may be unnecessary) and UpdateBatch.
This is virtually instantaneous.

I think that single record forms are superior in HTML.

Of course, there is no comparison in development time. Developing a good
HTML form is demanding not only of time, but of skill and, particularly,
of patience as well.

--
--
Lyle

http://www.virtualtimetable.com

[billmiami2]

Wow David! Did I touch a nerve somewhere?

Well, that would be because the form WAS NOT REALLY COMPARABLE.
You cannot replicate the functionality of an Access form of any
complexity in a web browser. It's simply impossible. <<

Sorry, but the forms were created to have exactly the same
functionality.
And if the Access form was slow to load, then you probably hadn't designed it very well. You don't need to go with unbound forms to
get efficiency in an Access form -- all you have to do is reduce the
dataset loaded to that which is necessary for the user's task, and
no more.<<

The dataset was reduced. Every query for every form element was set
with criteria so as to return as few rows as possible--a single row in
some cases. The only reason why I mentioned unbound forms was that the
web application was functioning in a way similar to that of Access
unbound forms (open connection, retrieve or run SQL, close connection).
And you wouldn't be sacrificing functionality,

as you would compared to the Access app. <<

You don't ALWAYS sacrifice functionality by going to a web interface.
It depends on what you're doing. In this case, there was no difference
in the functionality between the two applications.

Bill

[Trevor Best]

Lyle Fairfield wrote:

Could you explain which features of an Access form are not replicable in
html (written by ASP or whatever)?
Multi column list boxes, combo boxes. The ability to "type down" in a
combo box, to requery a combo box without reposting the form or loading
some messy popup form (that the browser will most likely not allow).

Granted that things like scrollable/editable subforms can be produced in
HTML but at quite a programming overhead compared to Access.
What about interfacely rich? Could the use of CSS create an HTML form
that might be richer in terms of alignment, hovers, text-decoration,
font-variant, margins, padding etc etc etc than an Access form?
You can decorate all you want in both Access and HTML, doesn't make
either more functional.
Regardless, do the clients/users ask, "Well, if there are 25
simultaneous users how many CPU's are doing (most of) the work?" If they
did, what's the answer?
In my case, the SQL Server :-) In any case, what would it matter? You
could ask how many CPUs are going to waste.
If there are 25 users are they all running the same application file on
the same machine? Or do they (somehow) run their own copy of the
application which hooks up with the db via TS?
Own copy, in their own profile.
How do TS applications fit with the idea of separation of data, business
logic and interface?

How do TS applications whose db is MS-SQL compare with ADPs in terms of
speed?

How do TS applications compare with DAPs in terms of speed?

You're asking questions like TS was part of the development, it's just a
comms program, it's the keyboard and screen.

[Lyle Fairfield]

Trevor Best <no****@besty.org.uk> wrote in news:42780849$0$2588$da0feed9
@news.zen.co.uk:

Lyle Fairfield wrote:

Could you explain which features of an Access form are not replicable in
html (written by ASP or whatever)?
Multi column list boxes, combo boxes. The ability to "type down"

I don't know what "type down" means.
in a
combo box, to requery a combo box
When do we need to requery a combo box?

without reposting the form or loading some messy popup form (that the browser will most likely not allow).

Granted that things like scrollable/editable subforms can be produced in
HTML but at quite a programming overhead compared to Access.

What about interfacely rich? Could the use of CSS create an HTML form
that might be richer in terms of alignment, hovers, text-decoration,
font-variant, margins, padding etc etc etc than an Access form?
You can decorate all you want in both Access and HTML, doesn't make
either more functional.

The interface then does not impact on functionality? Windows then is just a
pretty picture beyond DOS. I can go back to

@ 23,19 SAY ...?

and get the same functionality ...?

Regardless, do the clients/users ask, "Well, if there are 25
simultaneous users how many CPU's are doing (most of) the work?" If they
did, what's the answer?
In my case, the SQL Server :-)

I've questioned this for some time. With looping and conditionals and UDFs
and a number of built-in functions one can do all or almost all data
processing on the db server. But is this is a good idea? The server, I
expect has its own "internal" chores, updating indexes and the like. And it
has the db chores assigned to it by the uers, selecting, updating,
deleting, inserting etc. If I have an application that is calculation or
data stroking intensive do I want this work to be done on the server; do I
want it to be done on the server for 100 users whose own CPUs are at 2%
usage?

In any case, what would it matter? You could ask how many CPUs are going to waste.
Well, I would. If we have 26 CPUs I'd ask (as a client) why is one (or two)
assuming the db server is on its own box, doing all the work? Why did I pay
for the other 24 ball-busters?

If there are 25 users are they all running the same application file on
the same machine? Or do they (somehow) run their own copy of the
application which hooks up with the db via TS?

Own copy, in their own profile.

We must then create a profile for each person using the application?

How do TS applications fit with the idea of separation of data, business
logic and interface?

How do TS applications whose db is MS-SQL compare with ADPs in terms of
speed?

How do TS applications compare with DAPs in terms of speed?

You're asking questions like TS was part of the development, it's just a
comms program, it's the keyboard and screen.

Thanks. I remember now. Cobol. (Common Botulism Oriented Language)
Terminals with green on black mysteries. Minis and nylons underneath ... no
that was something else ... I mean ... attached to a mini ... I remember
wanting something? A techie would build a new "screen" ... in a few months
.... well ... if it could get on the priority list.

Why do we get rid of the mini-terminal model anyway?

--
Lyle

http://www.virtualtimetable.com

[David W. Fenton]

"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in
news:42**********************@news.optusnet.com.au :

I gather then, that the only real advantage of going to the web,
would be the benefits of being able to connect from anywhere. Is
that your understanding?

Well, so far as I can see, the only potential advantages of the web
would be:

1. no need to install Remote Desktop Connection on the remote
desktops (in order to connect to the Terminal Server). It's a pretty
minor installation, but it is one remote administrative component.
With a browser-based app, assuming you've written HTML that is
browser-agnostic (i.e., does not depend on Internet
Explorer-specific features or on MS's Office Web Components), then
anyone with a web browser and an Internet connection can use it. Of
course, there is Remote Desktop Connection client for Mac, and
there's even software for Linux to connect to Terminal Server. But
those all have to be installed, and that's an additional
administrative issue compared to the fact that nearly every PC in
the world that has an Internet connection already has a usable
browser installed.

2. support for more users for less money. A Terminal Server can't
support an infinite number of users. You have to allocate quite a
bit of RAM to each session, and there's a limit to the amount of RAM
you can put in a single WTS box. A browser-based application doesn't
have that restriction, as the number of connections is limited only
by the bandwidth, the ability of your HTTP server to keep up, and
the concurrency restrictions of your back end database.

3. administration. Some people think it's easier to administer a web
server than it is to administer a Windows Terminal Server. I'm not
entirely convinced -- I think an awful lot of people *think* they
know how to administer a web server, but really all they know how to
do is navigate the GUI for the IIS web services. I would *never*
expose a server in my office running IIS to the Internet, as IIS is
just too insecure (and too hard to keep up-to-date). I'd only ever
run Apache as a web server, as it's simply much safer than IIS. But
you lose the benefits of ASP and VBScript and the similarities to
Access VBA. Taking IIS out of the mix makes the browser-based app
much less attractive, as you have to write in a server-side language
that is less similar to what you're used to with Access.

Anyway, I'm all for hosting Access applications on WTS. I evaluated
it back in the days of NT 4, when it cost about $900/seat and you
had to re-install the OS (TS was not part of the base NT install,
but a completely different OS), and you had to purchase the Citrix
extensions to be able to do anything at all worthwhile. I was very
covetous of it, though, wishing I had it to support the
subcontractors working in their home offices.

Now it's a reality and pretty easy to set up and configure (though
the licensing management is tricky).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

bi********@netscape.net wrote in
news:11**********************@z14g2000cwz.googlegr oups.com:

You don't ALWAYS sacrifice functionality by going to a web
interface. It depends on what you're doing. In this case, there
was no difference in the functionality between the two
applications.

Unless you were using proprietary extensions like the dangerous and
buggy Office Web Components (which require the use of the execrable
Internet Explorer, which no sane person should be using any more), I
simply don't believe you.

But if true, the amount of time it took to replicate the
functionality of the Access app was probably many hours more than it
took to create the original app, unless the Access app was itself
remarkably trivial.

And, last of all, you can replicate the same functionality in a web
app that causes the user's experience to be vastly inferior to that
of the user of the Access app. If on the web you have to do 10 page
reloads in order to do the same thing that can be done in a single
Access tabbed form, then you may have gotten all the functionality
in there, but it's not nearly as usable.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Lyle Fairfield <ly******@yahoo.ca> wrote in
news:j4*********************@read2.cgocable.net:

Regardless, do the clients/users ask, "Well, if there are 25
simultaneous users how many CPU's are doing (most of) the work?"
If they did, what's the answer?
One CPU is doing the work, assuming all the users are connecting to
the same TS and the data engine is running on the same server. If,
however, the back end is SQL Server and is hosted on a machine other
than the one that's acting as TS (a preferred environment, of
course), then it's two CPUs.
If there are 25 users are they all running the same application
file on the same machine? Or do they (somehow) run their own copy
of the application which hooks up with the db via TS?
As Trevor says, you give each user their own front end, just like
with a LAN-based Access application. It's just that, instead of
being stored on each person's client workstation, it's stored on the
TS in the user's profile.
How do TS applications fit with the idea of separation of data,
business logic and interface?
The same way as any Access LAN application.
How do TS applications whose db is MS-SQL compare with ADPs in
terms of speed?
The same way as any Access LAN application.
How do TS applications compare with DAPs in terms of speed?

The same way as any Access LAN application.

As Trevor says, Remote Desktop Connection is just a screen, keyboard
and mouse that is an Internet connection away from the RAM where
you're running the application.

The main concern with TS-hosted apps is how much RAM you allocate to
the individual users, and figuring out how many simultaneous users
you're going to have. More is better, of course, but RAM is cheap
nowadays, and inexpensive blade servers can have gigabytes of RAM
installed for not a whole lot of money, in terms of cost per user.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Bob Darlington]

Thanks David.
You've given me exactly what I need.
I don't administer the TS server for my current client, but it certainly
performs well enough for me to recommend it to the new client for this
particular application.

--
Bob Darlington
Brisbane
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.90...

"Bob Darlington" <bo*@dpcmanAX.com.au> wrote in
news:42**********************@news.optusnet.com.au :

I gather then, that the only real advantage of going to the web,
would be the benefits of being able to connect from anywhere. Is
that your understanding?

Well, so far as I can see, the only potential advantages of the web
would be:

1. no need to install Remote Desktop Connection on the remote
desktops (in order to connect to the Terminal Server). It's a pretty
minor installation, but it is one remote administrative component.
With a browser-based app, assuming you've written HTML that is
browser-agnostic (i.e., does not depend on Internet
Explorer-specific features or on MS's Office Web Components), then
anyone with a web browser and an Internet connection can use it. Of
course, there is Remote Desktop Connection client for Mac, and
there's even software for Linux to connect to Terminal Server. But
those all have to be installed, and that's an additional
administrative issue compared to the fact that nearly every PC in
the world that has an Internet connection already has a usable
browser installed.

2. support for more users for less money. A Terminal Server can't
support an infinite number of users. You have to allocate quite a
bit of RAM to each session, and there's a limit to the amount of RAM
you can put in a single WTS box. A browser-based application doesn't
have that restriction, as the number of connections is limited only
by the bandwidth, the ability of your HTTP server to keep up, and
the concurrency restrictions of your back end database.

3. administration. Some people think it's easier to administer a web
server than it is to administer a Windows Terminal Server. I'm not
entirely convinced -- I think an awful lot of people *think* they
know how to administer a web server, but really all they know how to
do is navigate the GUI for the IIS web services. I would *never*
expose a server in my office running IIS to the Internet, as IIS is
just too insecure (and too hard to keep up-to-date). I'd only ever
run Apache as a web server, as it's simply much safer than IIS. But
you lose the benefits of ASP and VBScript and the similarities to
Access VBA. Taking IIS out of the mix makes the browser-based app
much less attractive, as you have to write in a server-side language
that is less similar to what you're used to with Access.

Anyway, I'm all for hosting Access applications on WTS. I evaluated
it back in the days of NT 4, when it cost about $900/seat and you
had to re-install the OS (TS was not part of the base NT install,
but a completely different OS), and you had to purchase the Citrix
extensions to be able to do anything at all worthwhile. I was very
covetous of it, though, wishing I had it to support the
subcontractors working in their home offices.

Now it's a reality and pretty easy to set up and configure (though
the licensing management is tricky).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Trevor Best]

Lyle Fairfield wrote:

I don't know what "type down" means.
You type something in a combo box and the selection moves down to what
you've typed
When do we need to requery a combo box?
Aw come on, you've been here long enough, it's an FAQ.
The interface then does not impact on functionality? Windows then is just a
pretty picture beyond DOS. I can go back to

@ 23,19 SAY ...?

and get the same functionality ...?
Point taken.
Well, I would. If we have 26 CPUs I'd ask (as a client) why is one (or two)
assuming the db server is on its own box, doing all the work? Why did I pay
for the other 24 ball-busters?
Not quite sure where you're going with this one, you appear to be making
a case against yourself :-)

If there are 25 users are they all running the same application file on
the same machine? Or do they (somehow) run their own copy of the
application which hooks up with the db via TS?

Own copy, in their own profile.

We must then create a profile for each person using the application?

User logs in, profile is created by Windows, happens on all NT kernels.

Why do we get rid of the mini-terminal model anyway?

'cause they require a team of (grumpy old) men in white coats to
maintain? Because everyone wanted their own PC. Gary Glitter wanted his
own hard disk to keep his pictures on in private. >-)

[Trevor Best]

David W. Fenton wrote:

1. no need to install Remote Desktop Connection on the remote
desktops (in order to connect to the Terminal Server). It's a pretty
minor installation, but it is one remote administrative component.
With a browser-based app, assuming you've written HTML that is
browser-agnostic (i.e., does not depend on Internet
Explorer-specific features or on MS's Office Web Components), then
anyone with a web browser and an Internet connection can use it. Of
course, there is Remote Desktop Connection client for Mac, and
there's even software for Linux to connect to Terminal Server. But
those all have to be installed, and that's an additional
administrative issue compared to the fact that nearly every PC in
the world that has an Internet connection already has a usable
browser installed.
The RDP client is already installed in later Linux distros, I've used
the one here (Suse 9.2 and 9.1 before that) and it works well. Also XP
has remote desktop client built in.
Now it's a reality and pretty easy to set up and configure (though
the licensing management is tricky).

TS Licensing... Arrrrrrrrrrrrg! :-)

2 Admins per box, no problem <vbg>

[billmiami2]

David,

Unless you were using proprietary extensions like the dangerous and buggy Office Web Components (which require the use of the execrable
Internet Explorer, which no sane person should be using any more), I
simply don't believe you.<<

Office Web components (OWC) is run on the server, not the client. It's
a lightweight, more web friendly way to produce Excel "spreadsheets",
charts and other files on the server. I've used it in the past but not
recently. There are no browser restrictions because, again, the files
are produced on the server.
But if true, the amount of time it took to replicate the functionality of the Access app was probably many hours more than it
took to create the original app, unless the Access app was itself
remarkably trivial. <<

Well....not really. This was because I used the Access app as a guide
for the web app. Therefore, all of the hard thinking was already done.
However, I would say that it still takes me somewhat longer to create
a simple web app than a simple Access app if I had to do them both from
scratch.

I do my web development with ASP.NET and I can tell you that it's a
wonderful thing to be able to create your own libraries of components
quickly and easily, completely object oriented, no registration
required. I try to mimic this in Access using subforms but it's not
the same. There's so much that I can do in .NET that I can't even
begin to think about in Access.
And, last of all, you can replicate the same functionality in a web

app that causes the user's experience to be vastly inferior to that
of the user of the Access app. If on the web you have to do 10 page
reloads in order to do the same thing that can be done in a single
Access tabbed form, then you may have gotten all the functionality
in there, but it's not nearly as usable. <<

Hmmm.... David--how much experience do you have creating web
applications?

Bill