>>Al,
>>
>>Thanks for the reply. Actually there is not problem with the set exclusive off
>>the program is perfectly run on a multiEvironment. The program is being used already in some of the asian countries, oil company, but lately i found out this bugs i am using also data Environment and these happens only for those major modules who uses the same file but i already declared datasession of form as private, i tried also to run it in different directory one is in c:\drive (in Executable)and the other one is in d:\drive using the source codes. But this happens also , is this pertaining to memory ? but this happens also in all the pc's.
>
>So, you're saying the program works fine when run simultaneously on multiple computers on a network, but not in multiple sessions on a single computer?
>
>This should not happen. What kind of network are you using? Some Novell network clients don't handle locking etc. properly.


This is not completely true;
Note : I'm note sure whether you start VFP twice or whether you use VFP once and have two datasessions; I think the first AND I have only experience on the first. For this matter :

The "reaction" of the OS is different on locking-topics for two tasks on one PC versus two PC's performing the same task. It's hard to explain where this is, but it is in the corner of File access denied on Exclusively used files by others (i.e. other task) or you needing exclusive access. This even depends on the client (indeed) and the NIC used.
Also low-level files IMO are opened differently for the "shared" matter. I mean, somehow a low-level file opened twice locally "acts" different from doing this on the server (by itself this is logic because treated by another phenomenon), but somehow this is related to the low-level use of two taks in one PC on the server-file versus two different PC's doing this.

In the end the same accounts for normal table-use.

Now this is only noticed when your error-routine is detailed enough to report on all errors there are. I mean, leaving it all to VFP may inform you about "locked" only, while detailing it all out including File acess denied (which is hard to do ! -> which file ?) learns that same base-situtions may lead to different originators. What do I say ? F.e. File access denied is received when I need a table which is opened exclusively by another, and when I need it exclusively. So, the originator is different, but the error is the same.
Now what this comes to, is once you are able to determine all these differentiations in your error-routine, it becomes easy to learn (see) that two tasks within one PC act differently to the matter of errors (given by the OS) than two PC's. And, since it is the OS reporting on the errors, and OSses are different here and there AND influenced by the Client (Novell, MS), it's all a very hard job.

Think also on the fact that once your error-routine is not capable of differentiation of all the situations which may occur, you may end up with a nested error or with a non-trappable error, and there you go.

Though I don't have the experience, I would say that even if you are working with datasessions, it is the same as two VFP-tasks, so the above may apply.

Now, I don't know whether this is (easy) possible, but maybe you try to shut off all error-trapping, and then see what happens ...

BTW, I assume it is not just VFP's Resource file you are dealing with here ? This is opened by VFP exclusively, and therefore you have a problem if you start VFP twice on one PC. (-> you can direct VFP per task to which Resource file to use i.e. you can have more on one PC).

HTH