From experience I can say that problems might occur if programs were compiled on a drive other than C:. Somehow FPW26 runtime running under Win95 looks for the original drive of the prg at design time (silly). Although it may not be the problem in your case, make sure all your programs/apps are compiled when on drive C: (which can be found on most computers at runtime) and than you can use relative paths in your programs.

HTH
Sorin


>>>>>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.