>Sandi,
>
>This unlucky user...
>
>Is that user's workstation the one where the tables reside, or did you do it on that machine (as mentioned below) simply as a test?

--- Yes the tables reside there

>
>Does the 'server' workstation regularly run other stuff while this user is at work in your app.?
>
------- Nope. Only regular windows stuff and sometimes a Foxpro 2.6 app too. I have had them close down the 2.6 app, but cant be sure they always do.

>Is the network cable between that user's station and the 'server' OK... can you replace it to see if it helps?

--- Same machine. Cabling was replaced recently and no other 'network' related problems.
>
>Is it possible that the user is somehow touching the network cable while they are working?

---- Network cables in back, client cant access.
>
>Have you checked ControlPanel-->System-->Hardware-->DeviceManager to check the 'status' of the network card and the workstation's hard drive?


--- Nothing unusual.
>
>How many other users regularly connect simultaneously to your app.?


-- In this case, only one or two others. In other cases 3 - 4.
>
>All in all, sounds like a configuration issue to me (assuming decentskills on the user's end).
>

- Also recently we noticed that emails from that machine were sending two copies, we changed some settings in Norton AntiVirus and that seems to clear that up so maybe this is also a Norton file issue.

Sandi


>good luck
>
>
>>Hi. I have a really strange problem at one client site. The client is running a peer to peer Windows XP Pro network. The app is VFP 7.0 Here's what is happening.
>>
>>In the app you can enter a value in a screen. (Payment method - a cheque amount). When you do the system checks a field on the same table and if empty inserts a record in another table (Receipt) and shows that record (ok so far) and updates the parent record with the key (doesnt happen), then you come back to the main screen and are moved to a field to enter a cheque number. The client does and the code requires that it find the record just stored and replace the cheque number (previously empty) with the one just entered. Then the client saves the record. When all is said and done, the receipt was created, the parent record did not record the receipt key so the cheque number is never recorded. I have other clients using this code without issue. I can use the client's data and press the exact same keystrokes and no problem occurs. This client also has a problem in other areas such as data 'disappearing' after a save.(screen goes blank, possible index corruption), going next/previous in
>>a screen and wrong values come up, posting and account numbers not captured. All in all there is alot of wierd stuff happening, but only at this site. I have other clients running the app, I can do the exact keystrokes using the clients data without issue. The problems occur when no one else is in the application, and when done directly on the main computer (acting as a server, where the data/program resides). I thought about opportunistic locking, but I thought Win XP defaulted it off by design. All the problems seem to relate to buffering, but the same 'code' is executed at multiple sites so I cant see it being the program itself - some wierd environmental issue. Any words of advice?
>>
>>TIA,
>>Sandi.