>>>I have a method that changes the .Database property of Cursor objects in the Dataenvironment to point to the correct data folder, rather than my development folder. I have .AutoOpenTables = .F. for these dataenvironments, and do DataEnvironment.OpenTables() after setting the property. I have one form where the OpenTables() was giving me the "Object is not contained in a form" error, which I asked about in another thread. Searching help for insight, I found this:
>>>
>>>"Note that setting a cursor object property at run time generates an error (with the exception of the Filter and Order properties, which can be set at run time). For a new property setting to take effect, you must call the CloseTables and OpenTables methods for the data environment."
>>>
>>>I thought that I was solving this common problem in the right way. What is the right way to ensure that a DataEnvironment opens data from the correct folder and not from some copy? This code has always worked, except for this one form, and the error doesn't obviously point to this rule.
>>
>>You are trying to solve it the right way, but someting has gone wrong. Howsabout posting your code that changes the database?
>
>Each form's DataEnvironment has .AutoOpenTables = .F. and .AutoCloseTables = .T.. In the .Load of two of my form classes:
>

>SET TALK OFF
>oChangeDataPath = CREATEOBJECT('datafolder')
>oForm = THISFORM
>oChangeDataPath.curfolder(oForm)
>RELEASE oChangeDataPath
>RELEASE oForm
>

>My datafolder classes has this code in its .curfolder method:
>

>PARA oFormcalled
>* This class resets the paths of tables in the data environment
>* to CURDIR()
>IF PARAMETERS() = 0
>   RETURN
>ENDIF
>IF TYPE("oFormcalled.DataEnvironment") = "O"
>   oEnviron = oFormcalled.DataEnvironment
>ELSE
>   RETURN
>ENDIF
>IF TYPE("oEnviron") = "O"
>   nTotMem = AMEMBERS(aMems,oEnviron,2)
>   WITH oEnviron
>      IF .AutoOpenTables = .F.
>* Check for cursors
>         FOR i = 1 TO m.nTotMem
>            IF UPPER(EVAL("."+aMems[m.i]+".BaseClass")) = "CURSOR"
>               WITH EVAL("."+aMems[m.i])
>                  STORE .Database TO cDB
>                  cDB = SUBSTR(cDB,RAT('\',cDB)+1)
>* The help implies that the .Database property shouldn't be
>* changed like this in runtime:
>.Database = SUBSTR(FULLPATH(cDB),1,RAT('\',FULLPATH(cDB)))+cDB
>               ENDWITH
>            ENDIF
>         ENDFOR
>* This line generates the error "Object is not contained in a form":
>         .OpenTables()
>      ENDIF
>   ENDWITH
>ENDIF
>RELEASE oEnviron
>

>The error happens when I start the form from another form which has one of the same tables in its dataenvironment. However, I have two other similar pairs of forms that work that way without error. If I go straight to the form from the main form, there is no error. In each case, the first form is based on one form class, and the second form is based on the other form class.
>
>I can see no essential difference between the affected pair of forms and the other two pairs. I tried creating the form again from scratch in case the form was corrupted somehow, but it made no difference.
>
>The form that generates the error used to have a private datasession. At that time, the error would occur in the other form that opened it, after entering, exiting, and entering and exiting some other pair of forms.
>
>Thanks for all the help.

If you are using this technique with any forms that do not have private datasessions, I could see where problems would occur. When a form that uses the default datasession has tables in its data environment, it doesn't open new copies if there are already copies open in the default session. YOu might want to run some checking, and only try to change this property if the form's using a private datasession.