05130400.txt 13-May-00

Terminal Server,WTS WinFrame,Citrix MetaFrame

Hi Jan Petter,
On Terminal server with the Metaframe add-on you could check
  the following things:
Check if the checkbox "Connect client printers at logon" is
  checked in the "client devices" group options in the "User
  Configuration" for a user that is having this problem.
You could find this option in "User Manager for Domains" by
  clicking on the Config button.
Check also the "Client Settings"(MetaFrame only) whether
  the" inherit user config" checkbox is checked and that the
  option "Disable Windows Client Printer Mapping" is not
  checked in "Client Mapping Overrides"
There are configuration options at different levels:
Connection Level, If you want to set an option that affects
  all users who connect to the server using a particular
  protocol you should set it at this level using the
  Terminal Server ConnectionConfiguration Tool. Settings at
  these level override the same settings set at the user- or
  client- level
User Level, The options set at this level apply only to the
  user that you set them for. These options can be
  overridden by the connection-level options.
Client Level, Options can also be set at the client
  software; the options only apply to the client connection.
  Just as with user-level options , the options set at this
  level can be overridden by the connection-level options.
Nasier

Hi Stephane,
Even we can adjust package and window size for TCP/IP
  protocol to optimize data through put, the solution still
  is reduce the raw data pass through the network.
For access data from a local harddisk, file will treat as a
  character string(or stream of data). When we seek for a
  record, index file will be read by a cluster basic to
  perform tree search. After retreive record number,  the
  particular record will be read by a cluster basic.  All
  this will same as performing a cC:=SUBSTR(?.dbf,nS,nC) or
  cC:=SUBSTR(?.ntx,nS,nC). The cC is the cluster read to
  memory.
Access data from a file server(LAN/WAN) same as about, but
  unit is measure by package. Try compare with 33mega byte
  per second (Ultra DMA Mode 2) harddisk through put to
  10mega bit through put(LAN) and 33.6kilo bit through
  put(WAN), we will see where are the problem is.
Database server will retrieve data and return the data set
  that matching selection criteria only, even for a single
  record this will avoid passing over index file's data.
Process server will retreave data and process it all at
  server site and return the result only.
Terminal login will get keyboard input and return screen
  output, all thing are done at server site, client just
  doing keyboard capturing and screen update only.
Impliment file server under WAN or large data under LAN are
  not practical due to we have no way to control data of
  index file pass through, and cache/buffer will not work
  for network data, and high band width network are so
  expensive.
Using database server like ADS(Advantage Database Server) or

  through ODBC when doing inquiry/report/processing will
  need high skill programmers to reduce data pass over to
  acheive satifactory response time. E.g. when browing whole
  company employee data, we should request for a screen full
  of data only instead of really request the data for all
  employee.
Terminal login(or PC environment call remote control) using
  PcAnywhere, or Citrix MetaFrame on top of WTS(Windows
  Terminal Server) WinFrame will overload the server but is
  easiest way to acheive satifactory response time.
Implement process server (SOCKET, RPC, DCOM, ADO...
  ) is a real solution under WAN or large data under
  LAN, since when a server been overloaded, we can add
  another server to distribute the workload. We can even run
  a process at NT, and using .dbf record or text file as a
  semaphore to communicate.
For your case I think now you should use PcAnywhere and
  spool report to a file at server site, later using a
  viewer to view or sent it to printer.
Wong

>Would TCP/IP be better ? Do I need an ISDN or T1 line ?
Winsock (used w/ IP) handles the 'change notification' to
  the other stations, DUN or not.  NETBuei does this as well
  - done by the workstation rather than the protocol.
Don't believe that NB is slower than IP, they just work
  differently and NB is more suspeptable to someone hacking
  in -- w/ IP the hacker needs to be something of an expert.
  If the client has a GOOD firewall - use IP, if not - stick
  w/ NB.
If the remote user needs exclusive access at any time, you
  will be safer w/ IP as the IP protocol will send the lock
  too.  As far as IP seeming faster, the responses via the
  protocol (vs. the app) seem faster becuse they are
  originating 2 levels higher on the OSI model.
FWTW - David

Yes,
this runs ok. You can use mailslot over a network or
  locally, and it's the same thing for socket. For
  MailSlots, look into the Win32 SDK at CreateMailSlot, you
  will find the remarks, how to set a local or distant
  mailslot. For Socket, notice that the current station can
  be adressed by itself using localhost as name or 127.0.0.1
  as IP address. I think both approach have there in and
  outs.
Fabrice.

Judd,
Have you thought about using it as a COM server ?
Michael

Yes, but not having done it before I wasn't sure how this
  would work.  I still want the app to be able to run on
  it's own.  Is this combination possible? Maybe the COM
  server would be a third app which both the message loop
  and the other apps would use. Is OLEAutoObject and
  RegisterOLEAutomationObject the way to go?
-Judd

Geoff,
> The registry approach obviously won't work on a network as
  you can't see another machine's registry.
In this case the info is all PC specific.  It's job is to
  set up and maintain data locally for the user to have
  access to when they are off the network.  Most of the data
  is already in the registry. IAC, at this point I'm going
  to look into using a OLE/COM server to do the work.  There
  is a nice sample of OLEAutomation in VO 2.5 that makes it
  look quite simple.  Since this is new to me I'm sure there
  will be a few surprises, hopefully pleasant ones ;-)
-Judd