Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
2.6 Windows Problem
Message
From
20/07/1997 12:59:27
 
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00040152
Message ID:
00040827
Views:
40
>>>>If this is on a network, check to see that all your users are not using the same resource file. This could cause the lock problem. You may be accessing the resource file at startup but setting resource to off later in your app. Some times two users could come on at the same time and get a conflict when they try to access the resource file (foxuser.dbf) at the same time.
>>>
>>>
>>>I have a few small apps that use foxpro and the foxuser.dbf file. Each one has that same copy in their own directory. Also I have some reports that run inside
>>>the main application and some that access those tables but run outside
>>>of the main application. All these reports are in the same directory
>>>and there is a copy of the foxuser.dbf in that directory as well as in the main directory of the main application.
>>>
>>>Do you think this may be causing a conflict with the main application that is producing the error messages?
>>>
>>>If this is so, would it be best to use the set command in the autoexec.bat
>>>to find the resouces in the same place rather than have multiple copies on the
>>>system? "Set FoxProW=p:\psmain"
>>
>>My applications all start from a config.fpw, inside that config file I set resource off. This is how I do it, it may not be what you
>>need, but I have found that if I need a resource file inside my application I declare it there with the command
>>SET RESOURCE TO filename and the SET RESOURCE To and SET RESOURCE OFF when that appilcation is done. I also ensure that the resource file residing on the network is set to READ ONLY. I do not user the foxuser file at all.
>
>Andy, double-check that ALL your 'outside' programs have SET Exclusive OFF.
>
>HTH
>Barbara
Thanks, but that was the first thing I thought of. I didn't have this problem when I was running the DOS version of this application. So that let me know that the code for the report that I wrote must be O.K. However I have found out that under Win95 the SQL Select does some odd things. I must of my code
I don't refer to a drive letter before a directroy. That way I can run the same code on my local drive and network drive without changing the code each time.
In WIn 95 sometime this work and sometimes it doesn't. I have one program that
will work on my workstation and 1 other but if 5 other people run it it returns
"can't find variable..." mesages. If I add the drive letter it works fine. Hence
I am rewriting all my programs that use the SQL Select.

It all started when I went to the Windows 95 platform and changed to the WIndows Version. See this application can be run in either DOS or Windows just by loading it in the plantform you want. The code was made to handle either. I didn't run this in Windows 3.1 so I don't know if it's a Windows 95 configurations problem or a Novell problem or a Foxpro problem

One thing I just noticed is that this application leaves a large number of tmp
files and cdx files in the Windows\temp directory. I have run into some strange behavior in WEIn 95 when there are files left in the temp directory. I just made a login script to delete all the files in the windows\temp directory of all work stations when they startup and log into the network. This may have to influence.
At his point I'll try anything.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform