>Al,
>
>I just wanted to say a big thank you for all your help on this issue, we had a meeting at the customer about this with the server supplier, I really felt well primed for the meeting.
>
>It soon became apparent that in my opinion Netserver is a simpler "file locking" program than Samba, & is probably not up to the job as far as giving Foxpro a stable enviroment is concerned.
>
>I tried to open a simple text file, and that took 30 seconds to open, so there is obviously still network issues with the IBM Server. They have since changed the mapping from a domain name to an IP address & that appears to have removed the network delay?
>
>Apparently there is a Linux partition that they use only to aunthenticate the users, as a final solution we may move the Foxpro Software onto there, with Samba running.
>
>Thanks again mate

Glad I could help. Hope it works out for you.

Cheers.

>>>Hi Al
>>>
>>>IBM i5 server running native file shares. Operating system is at version V5R4M5, i'm told its not running SAMBA, the old server was.
>>>
>>>I will be back to the customer tomorrow to have a look at the actual location of the server.
>>
>>From what you're saying, and after a little poking around the Web it looks like it's an IBM i series server, running the i5/OS operating system. This seems to be the descendant of the IBM AS/400 which ran the OS/400 operating system. This is neither Windows nor Linux.
>>
>>Samba runs as a process on a Linux box to provide Windows-compatible file and print services (SMB/CIFS) - in other words, to make the Linux box emulate or "look like" a Windows server.
>>
>>Equivalent software on an i5/OS system seems to be "NetServer" ( http://www-03.ibm.com/systems/i/software/netserver/whatsnew.html ). It is most likely the interaction of this software, the Windows workstations and the network connecting them that is causing your problems.
>>
>>You, or someone at your company will need to discuss this in detail with the administrator of the new server. They are unlikely to be familiar with VFP, so you will need to point out:
>>
>>- VFP is a "file-server" (or "flat file") database, which generates much more file i/o and network traffic than "client-server" databases
>>
>>- VFP makes extensive use of SMB file and record locking, as well as opportunistic locks ("oplocks") (where available). To improve performance it also extensively uses client-side data caching
>>
>>Combining the above, VFP has proven to be one of the most demanding SMB/CIFS applications in existence. It requires high-quality network connections with low latency, and full support of the Windows lock mechanisms. If there is any weakness or misconfiguration of a Windows-compatible (or actual Windows, for that matter) network, VFP will "find it". In other words, it will manifest itself as VFP program errors and/or data corruption.
>>
>>Questions you will probably want to ask:
>>
>>- Is a high-quality, low-latency network in place? It should be 100Mbit Ethernet or better, over Cat5e or better cable and with quality switchgear. For reliable operation, VFP apps should never be run over a wireless (e.g. WiFi) network connection. Ideally, VFP apps should be on a local area network (LAN), and not be run over office-to-office links (e.g. VPN or true private network over MAN or WAN).
>>
>>- Is the NetServer process configured to give good file i/o performance for Windows SMB/CIFS clients?
>>
>>- Is the NetServer process configured to give full support for SMB/CIFS file and record locks, and (if possible/available) Windows oplocks?
>>
>>- You might want to ask about the NetServer general configuration profile. For example, by default NetServer may be configured for a "typical" network that does not include demanding file-server databases like VFP. There might be another profile that better supports multi-user/high performance/high reliability operations. Such a profile might consume more resources on the server computer so the admin may be reluctant to enable it. Nevertheless, if a better profile exists it should probably be enabled for at least a trial period, for test purposes.
>>
>>- It's unlikely that the i-series server is running any kind of antivirus program. If there is AV on the workstations, you might want to try disabling the real-time scanner component (at least for all VFP file types), for test purposes. Real-time AV scanners hook directly into the file system; the AV vendors themselves may not have tested them against a NetServer file server.
>>
>>- If NetServer does not support Windows oplocks, you may be asked to disable them on the workstations. I'd do this only as a last resort; the workstations were working fine against a Samba file server. I haven't yet seen a complete list of all the registry tweaks needed to do this; the closest I recall seeing is a post from Tracy Holzer (message#892649). I think Neil McDonald has experience doing this as well. Maybe either Tracy or Neil could chime in.
>>
>>FWIW searching the UT on "AS/400" comes up with 360 messages. A lot of those seem to be regarding connecting to tables via ODBC, or to DB2 running on the AS/400, rather than using the AS/400 as a plain file server. I don't know how much information there would be relevant to your current situation but it might be worth exploring if all else fails.