Hi Al,

yupp, Tamar wrote that. As it is Tamar, I believe the statement to more than 95%.
I parsed the OP into something like: Yupp, data is guaranteed not to be pressed
to LAN wires. Tamar had tests done on server and on local machines.

My nasty 5% went: perhaps the code has some smarts hidden,
switching or massaging paths during install and
reading that info from a configuration file, leaving identical code

I have no war stories from TS optimization, but one from running 2 or 3 VMs
on first quad core CPUs. Conventional wisdom is, put exe and data local.
My special setup had each machine doing 99% with its own data sets, every 15m
a global status table was modified. I had experimented withsmall and large
memory for vfp, but also with defining different settings of VM RAM.
Bad thing was: each machine had via those settings a fixed HD memory cache,
when disks were spinning the unused RAM buffering HD was more signifiant.

One day I thought outside normal frames, created for each VM a special directory
outside all VHD on the host machine, cut the RAM of each VM by more than half and
started & accessed all tables on the host machine. As no LAN wires stemmed data flow,
the host machine now had excess memory to buffer data access for all 3 VM and
this used the physical RAM much better than "fixed" RAM buffering the "local" vhd data.

Benefit of buffering on host gave a stronger boost than piping the data through
TCP/IP stack without physical cables added as overhead....

special problem setting for sure - but in hindsight fooling around benefits made sense.

>Tamar said the production environment is running with local data and that she sees the same results running on a local workstation. If both cases are truly local storage (i.e. app on RDS is accessing data on a local drive letter) then SMB and the networking stack should not be involved at all.
>
>OTOH I've seen old apps with hard-coded data paths that need to run on both workstation and TS/RDS servers on the same network. The workstations require a separate drive letter such as F:, which means the same app running on the RDS server needs network mapping of F: to its own local storage/share (which is certainly possible). In that case SMB and networking are involved even though the ultimate destination is local.