>>>>>Hi All,
>>>>>
>>>>>Just in one week time we have two customers who have upgraded their workstations to Windows 10 calling for support because of our application errors out with a C5. The point of where it happens seems to be random.
>>>>>
>>>>>So far I have advised them to
>>>>>- Check the network driver
>>>>>- Check the printer driver and test while a different printer is the default printer
>>>>>- Check the graphics driver and upgrade that if needed
>>>>>- Disable the virus scanner temporarily to see whether it makes a difference
>>>>>
>>>>>- Delete the user profile on that machine and restart Windows
>>>>>
>>>>>Though I'm not able to check whether they all try that, it sounds like the problems are still there.
>>>>>
>>>>>This application has been very stable so far, and this particular build has been running on hundreds of workstations without a problemin the past, so I pretty much rule out it is our application.
>>>>>We are running our application with SET RESOURCE OFF, so it also does not have anything to do with foxusers.dbf
>>>>>
>>>>>
>>>>>Does anyone have the same experience with Windows 10 and a VFP9 app ?
>>>>>
>>>>>
>>>>>Walter,
>>>>
>>>>We c5 randomly on w7, w8 and w10.
>>>>I have not seen a worsening with W10.
>>>>
>>>>For us, the biggest problem is that messagebox not appears,
>>>
>>>You mean that it crashes without any error message?
>>
>>no. C5 show the crash message, but it is very rare.
>>
>>it is a general problem, with a frequency of 90% !
>>
>>messagebox does not put in the foreground window,
>>Application stopping, keypress events doesn't go into the messagebox, a pain!
>>On XP this doesn't occur!!!!
>>
>>By pressing ALT, Enter, Space, changing application and returning on VFP ...
>>and swearing, you can bring up the messagebox.
>>I tried it with a direct call windows api, setting any flags, but to no avail.
>>
>>>
>>>>and that cursors give random corruption errors
>>>>( redo same code and cursor works ! )
>>>
>>>We have seen that in the past in VFP8 and VFP prior to SP2. having a few SYS(1104) on strategic places (after REQUERY() and before TABLEUPDATE()) Fixed that.
>>
>>We try.
>
>We have a SYS(1104) just before BEGIN TRANSACTION

before I was accidental, now the error is constant.
now i can investigate