>>>I have a client that has a network setup where the data files for a FoxPro app are on a computer where the folder is shared and the other computers access that data using std. file and print sharing. So there is no file server and no domain. All users are part of a workgroup only, I believe. They should be moving to a "true" network with a domain controller, one or more servers, computers part of the domain, etc. However, if that does not happen or takes awhile, I'm wondering about how VFP performs in this environment (this is a FPW to VFP rewrite). I've always had clients with a "true" network setup, but I've heard the peer-to-peer setup can be problematic at times. Some issues in the current FPW app may be attributable to this setup.
>>
>>VFP apps can run quite well on small peer-to-peer networks if those networks have appropriate hardware and are properly configured. However, many are not - here are some issues I've encountered over the years:
>>
>>Computers:
>>- "server" computer is often an older machine that is not really powerful enough to act as both a user workstation and the network "server"
>>- older machines may be full of dust, with failing or dead cooling fans or other dodgy components
>>- lack of hardware reliability features such as RAID 1 or 5 disks, UPSs etc.
>>
>>Network infrastructure:
>>- old Cat3 or Cat4 wiring that is not able to support 100Mbit or 1000Mbit speeds. These days, for networking you should really be aiming for 1000Mbit ("gigabit Ethernet") which requires at least good-quality Cat5e cabling, preferably Cat6
>>- old network hubs or switches that are only 10Mbit capable
>>- patch cables that are badly kinked behind desks, that get run over by desk chairs etc.
>>- lack of UPSs on network switchgear
>>- attempting to run VFP apps over a wireless LAN connection. This is a bad idea. These connections are subject to interference and unreliable, as well as being relatively slow - max theoretical throughput is usually 54Mbit (sometimes 108Mbit), and real throughput is usually considerably less
>>
>>Software:
>>- workstations running Windows 98 or Me
>>- "server" computer running W98 or Me (ugh), or XP Home or XP MCE
>>- XP Home or XP MCE machines on a network that is otherwise XP Pro. Those versions are variously crippled in network and management capabilities. XP Home can't join a domain if you install one later; MCE can but it's a tricky hack (not sanctioned by MS)
>>- hitting, or inadvertently exceeding the 10-connection limit for peer-to-peer networking (usually on the "server" computer)
>>
>>Network configuration:
>>- DNS: XP and above really prefer using an MS DNS server (as provided with MS Server OSs). Instead, on many small networks with a shared broadband Internet connection, every machine's DNS servers may be set to the ISP's DNS servers, or even to the network router. ISP-class DNS servers don't support all the RFCs that MS DNS servers do, and a router may not have enough computing horsepower or memory to offer high-performance DNS resolution. DNS resolution issues slow networks down a lot
>>- WINS server: lack of a WINS server on a peer-to-peer network can slow NetBIOS operations
>>- Network browsing: all SMB/NetBIOS (MS file and printer sharing) networks require a Master Browser computer, which is responsible for maintaining the list of shared network resources. When a computer boots and joins a network, by default it checks to see if it should become the Master Browser (for general info, not updated for Server 2003 and XP/Vista see http://support.microsoft.com/kb/188001). On networks with a "real" server/domain controller, the server is always the master browser and all is well. On homogeneous peer-to-peer networks (e.g. all XP Pro), an election may be forced each time a machine boots up (usually appears as master browser election messages in the System Event logs). This can interrupt or disrupt network operations. It's possible to edit registry entries to prevent machines from trying to become master browsers but it's non-trivial. Basically you'd want only the "server" machine to try to be a master browser, and you'd have to ensure that it was booted up
>before
>> all the other ones
>>
>>"Server" computer configuration and usage:
>>- Computers acting as servers must be stable and reliable above all else. This means proper installation of stable, correct drivers, elimination of extraneous software (anything that doesn't absolutely need to be running), regular file system maintenance, reliable backups etc. Most of the time, workstations that are pressed into service as network "servers" do not meet these requirements
>>- if the user at the "server" computer runs a task that crashes it, shared VFP data will often be corrupted
>>- if the user at the "server" computer runs a disk- or CPU-intensive task, this can cause large slowdowns in network performance for other users of a shared VFP app. This could be running your VFP app locally, running a game or Photoshop, or even something as dumb as having a CPU-intensive screen saver like 3-D Pipes
>>- some workstation OSs let you change default task priority to background tasks instead of the default foreground tasks, but most people running peer-to-peer "servers" forget to do this. In a lot of cases it doesn't help much anyways
>>
>>So, once you take care of all of the above, VFP runs quite well peer-to-peer ;-)
>
>Wow, did you really type all that in! Thanks for all that info. I appreciate the detailed nature of this. It looks like it would be a good posting on the Wiki. We should be moving away from this setup in the home office, but I'm not sure about the branches (at least the traffic will be lighter there). Thanks again.

You're welcome. I think I feel the need to do a "brain dump" once in a while ;)