>>>>>>>>Sylvain,
>>>>>>>>
>>>>>>>>I am out of the office at a conference now so I can't test what you have said. I have SET EXCLUSIVE OFF where I set up the application environment before I load any forms. I shouldn't need to do it again should I?
>>>>>>>>
>>>>>>>>
>>>>>>>>>Try inserting this line in the DataEnvironment BeforeOpenTables() event:
>>>>>>>>>
>>>>>>>>>SET EXCLUSIVE OFF
>>>>>>>>>
>>>>>>>>>HTH

---

>Thanks for the reply Sylvain. The offending form has nothing in the Load() event. In the dataenvironment I have 12 tables, no methods, and AutoOpenTable and AutoCloseTable is set to .t.
>>>>>>>
>>>>>>>If your forms use Private Datasessions, then yes, you'll need to do it in the Load method of each form. It's best if you put that in your base-class form's Load method.
>>>>>>
>>>>>>Fred,
>>>>>>
>>>>>>I didn't realise but I do have SET EXCLUSIVE OFF in my base-class form's load method, and yet I am still getting this same error. I use default data sessions as well. I am now getting a bit frustrated with this problem. Any more ideas would be greatly appreciated.
>>>>>>
>>>>>>Thanks, Peter
>>>>>
>>>>>Which forms are getting the error? The Private Datasession forms, or the Default Datasession forms? If it's the Default sessions, you still need to have a SET EXCLUSIVE OFF somewhere in your main startup code for your app (or even EXCLUSIVE=OFF in your CONFIG.FPW). Maybe you should check what your current setting for EXCLUSIVE is in the debugger (SET('EXCLUSIVE')).
>>>>
>>>>Fred,
>>>>
>>>>Thanks for the reply. Well, I have learned a bit more. Set Exclusive is set to OFF everywhere. And I am only using Default Datasessions for all these forms in question.
>>>>
>>>>What I have learned is that the Load event gets executed for the called form, but the Attempting to Lock occurs when running the Init event. The first line in the Init even is the PARAMETERS statement, since this form is called with a DO ... WITH command (a leftover from my Clipper days). It cannot get past the PARAMETERS statement. Are you aware of any problem here?
>>>>
>>>>Thanks, Peter
>>>
>>>
>>>It's probably some code in one of your control's Init methods. The form's Init doesn't fire until all of the controls on the form are initialized. The only thing I can suggest is to step through ALL your code when that form is brought up to see exactly what is happening.
>>
>>Fred,
>>
>>Thanks for getting back to me. Well, I think I have worked out my problem. I use a cursor in this form, and I was reading in the documentation that cursors are opened exclusively regardless of the SET EXCLUSIVE command. I guess I will have to rewrite this entire section of code to use arrays or use a permanent table.
>>
>>Thanks again, Peter
>
>Peter, what are you trying to do with this cursor? Cursors ARE opened exclusive, but any form can still write to it within this running copy of VFP. You can't re-open the cursor in a another datasession, or open it in another copy of VFP. A cursor created with SELECT is read-only, but even that can be changed with a USE ... AGAIN. Exclusive use does not preclude YOU from writing to the cursor, but read-only might.

Fred,

Thanks for the reply. I guess I'm not sure I understand how cursors work in a multiuser environment. Here is the code I use to create the cursor in the load event of the form that calls the other form that I am having trouble with.

select 0
create cursor saletemp (stock_no c(5),desc c(40),qty n(8),price n(12,6),category c(1),cost n(12,6))

Now that I think about it, I am able to write to this cursor just fine in the form it is created in, it is tied to a grid. My question is what happens to the cursor when I call the other form? I thought that was my problem, maybe it wasn't.

Thanks again, Peter