>>>>>>>>>>>>>>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
>>>>>
>>>>>If the other form has a private datasession, it won't be able to use the cursor you created in the first form. Maybe what you should do is make the second form modal, and set it to use default datasession. A modal form with a default datasession, brought up on top of the first form with a private datasession, will be able to share all tables and cursors that the first form opened. Clear, or did I just confuse you more?
>>>>
>>>>Unfortunately (for me) this is exactly how it is set up. The first form has default datasession, the second form is modal and default datasession, and I am still having the same problem. I have been through everything I can think of, I guess it must be one of the controls in the second form, but I have been through every control individually and I didn't find anything. I guess my next step is to delete controls one by one until I can isolate which one it is.
>>>>
>>>>Thanks again, Peter
>>>
>>>
>>>Exactly how are you trying to bring up this second form? If it's in the click method of a command button, post the code that's trying to bring this form up.
>>>Somethings you can try first:
>>>Where ever you're trying to bring up this second form, comment out that code and replace with a simple messagebox() call to just see if the second form really has anything to do with the problem or not.
>>>If no success there, you'll really need to step through the code of the second form and see exactly which line of code is causing the "attempting to lock" error.
>>
>>Fred,
>>
>>Here is the code for that is in the Click method of a button in the first form:
>>
>>if thisform.orders1.valid_order
>> select invoice
>> m_inv_no = inv_no
>> select customer
>> m_cust_no = cust_no
>> do form ordertot with m_inv_no, m_cust_no to m_return
>> if m_return && order was successfully saved
>> release thisform
>> else
>> select saletemp
>> thisform.orders1.grdbase1.setfocus()
>> endif
>>else
>> select saletemp
>> thisform.orders1.grdbase1.setfocus()
>>endif
>>
>>Saletemp is the cursor that is tied to the grid. As I said the program does execute the Load() event of the called form, so I will try to step through the code as you suggest. It may take me a while.
>>
>>Thanks again, Peter
>
>OK, once you get into the Load method code for your 2nd form in the debugger, go out to the command window and enter just the command SET. This will bring up a window that you can choose which datasession you're looking at and can see what tables/cursors are available in each data session. Your 2nd form's datasession should be at the top of that list. Let's see what that tells you.

Fred, Thanks for persevering with me. I have been caught up with other things lately, and I will be looking into this more tomorrow.

Thanks, Peter