>>>>> >>>>>Try running IPCONFIG /ALL from a command prompt. That should show you the main networking settings. >>>> >>>>I ran IPCONFIG this morning, earlier... >>>> >>>>IP - 192.168.1.100 >>>>Mask - 255.255.255.0 >>>>Gateway - 192.168.1.1 >>>> >>>>I also pinged the PC, the Network Card and the Router - all seemed ok. >>> >>>That is a very typical private address space setup. If you can ping between machines (they will all have 192.168.1.xxx addresses) then the networking is setup OK. >>> >>>as suggested by various people, make sure.. >>> >>>Run the EXE from the local machines - do not run from a network share! >>> >>>Make sure the EXE and DBF/FPT/CDX/DCT/DCX/DBC files are excluded from virus scanning. >>> >>>Make sure temp files are going to the local machines! >>> >>>Make sure no kinks in network cables - especially ones connected to the server or router/switch/hubs!! >>> >>>Make sure client machines have enough memory! >>> >>>This isn't a wireless LAN is it? >> >>No, all cabled. > >Bill's right, this is a pretty typical P2P private LAN setup. BTW how many workstations are there? > >My guess is that little, or nothing has been done to optimize the "server" computer in this P2P configuration: > >1. A router at 192.168.1.1 is doling out IP addresses, with the DHCP scope starting at 192.168.1.100 > >It's often a good idea to give a "server" PC a fixed IP address. In this case it should be outside the DHCP scope, so the DHCP server in the router doesn't try to give an IP address to another workstation that's the same as the "server's". For example, the IP address could be fixed to 192.168.1.2. > >An advantage of doing this is that you can experiment with mapping drives on the other workstations using this IP address rather than the server computer's NetBIOS name. So, instead of > >NET USE F: \\ServerPC\NetShare > >you can try > >NET USE F: \\192.168.1.2\NetShare > >This would remove NetBIOS resolution issues from the equation (see next). > >2. The "server" probably has not been designated the master browser computer > >Every NetBIOS network requires a "master browser" ( http://support.microsoft.com/kb/188001 ). If all computers in a non-domain network (i.e. P2P) have the same OS there is no obvious master browser. Whenever one computer starts up or stops, this may force an "election" on the network and generate messages such as EventID 8003 in the System Event Logs of various computers. It is possible to enable/force this service on some computers (i.e. "server") and disable it on the others. Details at http://www.chicagotech.net/browser.htm > >Before doing this, try accessing the server's shares via the fixed IP address in #1. If doing that makes no difference then #2 is unlikely to be the problem. > >3. The "server" computer overall task priority is probably still set to favour foreground tasks instead of background tasks > >By default workstation OSs such as XP give higher priority to foreground tasks (i.e. your app running locally) and less to background services (i.e. network file sharing for everyone else). You can control this via > >Control Panel...System...Advanced tab...Performance...Advanced tab...Processor scheduling (set it to "Background services") > >Also, fire up Task Manager on the "server" and check that it's got enough RAM, that it's not CPU-bound etc. > >4. The DNS server setting for all computers is probably the router/gateway (192.168.1.1) or perhaps their ISP's DNS server(s) if the router is just passing those values through via DHCP > >In my experience, XP and above really prefer to deal with Microsoft DNS servers (included with MS server OSs). This is because the MS DNS servers support various DNS functions ("RFCs") that are not supported by non-MS DNS servers such as may be found in SOHO routers or ISP-class *n?x-based DNS servers. Also, if there are more than a few active computers on the P2P network (say, more than about 5) they may create enough DNS traffic to overwhelm the DNS server in the router (which is usually a pretty low-performance processor, maybe only ~200Mhz/32MB RAM or less). One quick test to see if DNS may be an issue: > >- open up Word on a "workstation" >- create a new document >- try to save this to a share on the "server" computer. If this takes a couple of seconds or less, DNS is probably OK. If it takes 20, 30 seconds or longer, you could have a DNS configuration problem > >I could go on and on with ideas. When you've got a nagging problem network you need to get someone on-site who knows what they're doing. Troubleshooting starts from the bottom up: > >- good clean electrical power >- good quality cabling (pref. Cat5e), both in the walls and patch cables at the workstations >- good quality switchgear (100Mbit or better), switches > hubs, no or minimal switch interconnects ("daisy-chaining") >- reliable NICs in the workstations, properly configured for the rated switchgear speed (i.e. not throttled down to 10Mbit if the network supports 100Mbit) >- best-practice IP/DNS/Gateway configuration >- proper NetBIOS/NetBIOS over TCP/IP/Master Browser configuration >- disable unused protocols on network devices such as network printers (especially AppleTalk). Many network printers esp. from HP come with up to 4 protocols enabled by default, e.g. TCP/IP (you need that), IPX/SPX (Novell), NetBEUI (old WfW networks), and AppleTalk. >- sufficient RAM and CPU on the "server", plus plenty of free disk space > >In a perfect world, no antivirus suite would be required. IIRC you said they're running some kind of Symantec AV suite. IME there are 2 types: > >- the "Corporate edition", usually installed in large environments by professionals, and which seems to work OK in my limited exposure >- the "Personal edition". Small networks often have multiple copies of this personal edition talking to each other. AFAIC this latter product is a piece of crap. I can't recall a single time where I've encountered this product and it has NOT been screwing up the LAN, whether through incorrect "automatic configuration" of peer-to-peer firewall rules or just because it's such a resource hog that RAM, CPU or disk I/O get exhausted on critical machines. If you can, get rid of Symantec personal - replace it with a simple AV product w/o firewall and use XP's built-in firewall instead. I've had good luck with the basic paid AVG antivirus product (w/o firewall). If you can't get rid of Symantec, disable its firewall and revert to XP's built-in one instead, and exclude VFP file types from real-time scanning. > >Craig is also right, that some of these problems go away if you're using a real MS server. Small Business Server 2003 R2 offers excellent value and is designed to be easily managed by small businesses. IMO (and that of my clients) its remote-access Remote Web Workplace feature is worth the price of admission all by itself - think pcAnyWhere on steriods. > >So, now you've got a few things to think about < g > Unfortunately, for a network to work optimally, everything must be right - any single thing wrong means slow at best, non-functional at worst. Again, sometimes having "boots on the ground" is the only way to spot the patch cable that gets rolled over by someone's desk chair, the server power supply fan that isn't turning or is clogged with dust, the switchgear on the same circuit as the arc welder next door... > >Good luck!
Thanks! Lots of good stuff to investigate...........
I'll let everyone know how it turns out later today!
