Wow, thanks for the primer. I can see I've got a lot more to learn
about this...
bill
[EMAIL PROTECTED] wrote:
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. With
terminal services, if you drop a connection, you can reconnect
back right
where you left off. No database corruption to worry about. All
network
resources are available as well. Another big plus, is that you
can connect
to your network any where an internet connection is available,
same building or
50 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.
>
--- RBASE-L
================================================
TO POST A MESSAGE TO ALL MEMBERS:
Send a plain text email to [email protected]
(Don't use any of these words as your Subject:
INTRO, SUBSCRIBE, UNSUBSCRIBE, SEARCH,
REMOVE, SUSPEND, RESUME, DIGEST, RESEND, HELP)
================================================
TO SEE MESSAGE POSTING GUIDELINES:
Send a plain text email to [email protected]
In the message SUBJECT, put just one word: INTRO
================================================
TO UNSUBSCRIBE:
Send a plain text email to [email protected]
In the message SUBJECT, put just one word: UNSUBSCRIBE
================================================
TO SEARCH ARCHIVES:
Send a plain text email to [email protected]
In the message SUBJECT, put just one word: SEARCH-n
(where n is the number of days). In the message body,
place any
text to search for.
================================================
