Hello Charlie

i was under the impression that if you call any function (method in a class, or in a procedure file) from a form, the datasession is automaticly the one set from that form. in any case the funy thing is, that the 1st custom class on the _screen (called from the form) does inherit the datasession from the form, but the 2nd custom class (called from from the 1st class) does not. that's what puzzels me. if neither one of the custom classes would be in the datasession of the form, i would understand your statement, however they are not.

as you might have read in this thread, i've found a solution where i 're-set' the DS in the first class just before i call the 2nd class. it sure is wired!


>Hi Gunnar,
>
>_SCREEN.DBFOpen is an object that is contained in the screen. Objects automatically use the DataSession they were created in so..., any methods called in DBFOpen will be in DS1. I never use SET DATASESSION except for debugging. If you need access to a cursor, you must create the objects you need in the datasession you will use them in.
>The VFP way of switching datasessions is a very good thing. It's what enables you to say:
>Form1.Save()
>Form2.Revert()
>and have both forms operate in their own DSs without any SET DATASESSION stuff from you.