Two more questions in that regard:
1. When several clients use the database concurrently, it would seem the
thin client (let's say TS) server has to provide a separate instance of
the front end to each of those clients. How does it do this? Does it let
each of them click on an icon which opens a separate instance of the app
for each of them?
Each user gets their own logon, and each user gets their own private session
of windows here. The rule that we hammer out over and over again in this
newsgroup is that you do NOT want to allow multiple users into the SAME COPY
of the Front end. So, when you use terminal services, once again, you give
EACH USER THEIR OWN copy of the front end, and it will be trouble free.
In fact, you *can* actually allow more then one user to logon to the same
user, and get the same desktop etc, and then you would in fact be running
multiple copies of the same FE. (this will work, but is less reliable, and
as we mention OVER AND OVER again, don't allow multiple users into the SAME
COPY of the FE....as this leads to data corruption.
Do note that TS does virtualizes the copies of ms-access running, and
actually only loads ONE copy of ms-access. This means that most quality
software written for the windows 32bit environment is what we call
re-entrant (a fancy term for the fact that the memory used by the software
is swapped for each user...but only ONE copy of the software is actually
loaded. So, if you got two remote users running ms-access, there is in fact
only ONE copy of it running in memory!!). However, while ms-access (and most
products) are re-entrant, the locking, and other issues cause problems when
multiple users open the same front end file (which is preferably a mde). So,
while multiple users can in fact run the SAME ONE copy of ms-access, those
multiple users should not hit the same front end
At any rate, since each user gets their own desktop, their own logon etc,
then each user connecting to this server does not bother the other users. Of
course these shared FE's all do link to the same back end. So, the setup is
much the same as on a local office LAN. In fact, since there is NO data
transfer across a network from the FE to the BE, often those remote users
way far away get BETTER performance then users in the office who also have a
FE connection to the back end, but of course their connections have a
network in-between.
2. In most of your comments about TC, you seem to view it as a good idea.
But then at the end of your comparison of TC technology with dot net, you
argue that dot net is even better because it provides for interprogram
communication, whereas TC only controls one program at a time. But I
don't think I've grasped the reason for your conclusion.
Well, in fact,the article really is pressing the issue of thin client in
terms of using a browser foremost. You see, lets assume you run two separate
windows, one is a remote TS window connecting to your ms-access application.
And, lets assume you fire up another window that is running ms-word (on a
different server). Ok, now, how can you do a mail merge between the two
windows? Answer: you can not!! So, all I am saying that thin client allows a
person to remotely use some software across the web, but thin client does
supply the means for that software to communicate with other applications
you might be running across the web. Before we only ran applications
on ONE computer. Now, with everything connected, we need
a new way to allow software to talk to other systems.
(.net solves this problem and
address the fact that software needs to talk to each other
just like it does on your desktop, but now we run
software across the web and from *different* machines).
So, .net simply allows software to talk to each other
as if it was on one machine, but now that machine is
the whole web...and that is a amazing concept.
For the most part, my users need to go into the Access application, enter
data, and generate queries and reports. Why is inter-program
communication of concern to them?
In your case, it is not. Further, you are with TS exposing a full windows
desktop remotely to the user. So, in effect, you are not really solving the
problem of how other programs you run will talk to each other
(since all your programs on in the SAME window!! You
are just using a desktop remote...not one of the many web
solutions. How about having yahoo talk to ms-access? Even
better is how about having ms-access lookup the temperature,
or get flight information. Or, how about you get ms-access to
automatically fix a address you just entered, and also lookup the
zip/postal code for you. Do note, that MS has released the
soap ad-in for office, and thus as I write this, ms-access can
in fact consume .net services right now!!
If they need to export a query view to say, Excel, can't they perform the
export and then open Excel (just like they opened Access) since they're
controlling a portion of the server, and view the result?
Yes, absolutely, they can. However, this is because you are exposing a full
windows desktop to the end user. In the case of running software on two
different boxes remotely, or in fact if you are running your software throw
a browser (this is non TS solution), then each window you have cannot
communicate, or talk to other applications in other remote windows.
So, note how that article starts out referring to remote applications that
run
in a browser. So, my point was is that all companies have now figured
out how to make REALLY very nice interfaces via the web, but
that is NOT the problem that needs to be solved!. The problem here
is that if you use quickbooks via the web (which they now offfer)
and run it in a nice browser window, and then run excel (in
another window from some toer system), then the two
programs cannot talk to each other. So, my whole point here is that
the probelm that needs to be solved is not just using software remotlery,and
the problem is NOT makcing a real fancy windows interface. The problem that
needed to be sovled where is to allow software to TALK to each other.
Thus...we got .net...
Right now, you can write some code in ms-access, and set a reference in the
tools->references to Excel, and use Excel commands and automate excel right
inside of ms-access. You can also do the same with Outlook.
Well, with .net, you can actually do the same thing, but that program
reference you just set tools->references can be on any machine on the world
wide web that exposes web services. So, .net is the extension of allows
software automation and communication over the web.
