>>>
>>>Where is your code for field validations? If its in a procedure file or in code that calls the form, you'll have problems accessing the private datasession for a form. VFP insists on changing the datasession for exteranl code to a form back to the default session. Its not recommended practice, but you COULD change the datasession in your external code (SET DATASESSION TO _SCREEN.ActiveForm.DataSessionID). If the validation code is part of the object on the form, you don't have the problem of the datasession being changed.
>>
>>The form(s) are being called either by a menu hit or a prev. form...the actual validation code is in one of the form's UDF methods ..which is called from the "valid" of each field to "validate" the fields contents....
>>The datasession is already changed/changes when the form is activated...I assume because the "READ EVENTS" was executed at the "DEFAULT" datasession level?
>
>If the code is part of the form, you shouldn't have problems. Validation code should be part of the object it's validating, though.
>
>Where the READ EVENTS is has no bearing on the datasession. That's controlled by the form. (For some real amusement, put a SET('DATASESSION') as a watch point in the debugger, and move your mouse around over your form and then over the main VFP background. You'll see the datasession change as the mouse moves.)

Well in all actuality, the code isn't the problem...the datasession changes to the default when the form is displayed. It still maintains it's own "Private Data Session", but it isn't the current one. I've even checked this on other applications..(ie..VFP's canned "Solution" app). It's "modeless" forms have the same behavior..they maintain they're own "datatsession", but when you suspend and check the current datasession,with the form as the active object, it's always the "Default" datasession....