First, you do not have to make terminal services accessible to the internet. It will run soley on your
LAN just as well. Using the internet is very handy however, for remote trouble shooting or other
maintenance work. I have two remote faciltiies that run all programs from a central office however and
I love the setup.
As far as security goes, you can go a number of ways. Secure VPNs that use hardware can be virtually fool proof (but the hardware is more expensive) to using standard software encryption. (I have never had problems nor heard of anyone having problems with this. Remember with terminal services, your database is not being transmitted over the network, simplye the keystrokes and screen display.) Your wireless LAN theoretically can have many of the same, if not more security issues than internet Terminal Services. However, as mentioned, you can set up terminal services so that it is not even available to the internet, strictly your local LAN.
As far as speed goes, you will not get any faster. All processing is done locally on the server and no database data is sent to the remote. 801.b runs only 11 mb and g runs 54mb at perfect signals. You run bus speed with terminal services. Even with the highest level of encryption, you will still see faster speeds. Also as mentioned, since the database is not opened by the remote processor, if you drop your connection, no problem since the
process is still running fine on the server. I have some very database intensive programs that I run on terminal services from my desktop because it runs so much faster. Again bus speed versus sending hundreds of megabytes over 100 mb lan allows for much faster processing.
As with all things, there are pros and cons, but I have found very few negatives with TS. I am currently
planning on implementing all our factory control with it and not placing processors on the plant floor at all,
just dumb terminals.
If you are going to have only one wireless or remote unit, it would be less expensive to simply network over your wireless acess point. But you do need to plan on loss signals etc. and how to handle them. Otherwise it is fairly straight forward and certainly is a viable option. Many portable units still run only 11mb, so plan on some slow speed. I have not seen a lot of difference in 54mb however.
-Bob
-------------- Original message --------------
I'm kinda new to this idea, but I assume that means using TCIP type connections? It also means opening up the database to the internet, I suppose, which is kinda scary to me. I mean with thousands of SSNs, birth dates, etc. in my database I'd have to have a VERY safe connection, right? And if it's all encrypted, doesn't that slow things down a bit? I don't like waiting...
w.stacy
[EMAIL PROTECTED] wrote:
I have not used a tablet style, but I have used smaller hand held units.However, I employ terminal services instead of a direct network connection.That way, I do not have to worry about dropped signals etc. Withterminal services, if you drop a connection, you can reconnect back rightwhere you left off. No database corruption to worry about. All networkresources are available as well. Another big plus, is that you can connectto your network any where an internet connection is available, same building or50 states away.Tablet style PC's should work with remote desktop / terminal services as well.-Bob-------------- Original message --------------
> Has anyone tried to link a tablet style, wireless computer to a regular
> R:base database on a server (in the same office building)?
>
> What are the connectivity issues, software handshaking, etc, as well as
> reliability and speed, if any, concerns?
>
> Thanks. I think that is the direction I want to go, if feasable.
>
> w.stacy, o.d.
>
