Hi Maltsev Max!

Методы объекта всегда исполняются в той датасессии. в которой был создан и
сам объект. ЕСЛИ только принудительно не переключать эту самую датасессию.
Что касается твоего случая - то наверное лучше отказаться от такого
глобального и универсального класса - оставь в нём лишь установление
соединения, а сам запрос делай в другом месте - в методе формы, в другом
объекте, создаваемом в контексте формы, в простой процедуре наконец...

Posted via ActualForum NNTP Server 1.3

Hi Maltsev Max!

> Дак хочется же как лучше !!! :-))

И очень хорошо!

> В идеале планировалось создать несколько универсатьных классов, которые
> будут отвечать за работу с БД. А на форме юзать их свойства и методы ...

Так и делай! Только создавай эти объекты именно в той форме в которой они и
будут использоваться! ИЛИ полностью откажись от идеи использовать курсоры
для доступа к данным - т.е. работай ТОЛЬКО со свойствами и методами таких
объектов - тогда будет без разницы в какой DS находятся "подлежащие"
курсоры.

2 Aleksey

Честно говоря я не знаю где описано (и описано ли вообще) подобное поведение
ЛЮБЫХ фоксовых классов - если объект не порождает свою собственную сессию
данных, то он живёт в той сессии в которой он был создан - в частности форма
которая не породила свою сессию прекрасно видит курсоры "родительской"
формы - это так-же справедливо для объекта любого другого класса.
Что касается DataSessionID - это не более чем редиректор вызывающий
SET("Datasession") - если ты где-то в коде формы дал явную команду SET
DATASESSION TO zzz - то свойство DataSessionID будет показывать это самое
zzz - а вовсе не идентификатор датасессии, которую породила эта форма -
потому то и сохраняют при переключениях датасессии старое значение в
отдельном свойстве, или локальной переменной - а не используют DataSessionID
для "возвращения" в родную датасессию.
А хранит объект признак той датасессии в которой он "работает", а так-же той
в которой он был создан где-то во внутренних своих свойствах. Я не знаю
способа напрямую "достучаться" до этих свойств извне объекта - хотя до того
который хранит "рабочую DS" можно достучаться из любого метода объекта через
SET("Datasession"). А вот как достучаться до DS в которой объект был
порождён я вообще не знаю - причём что самое печальное - эта DS будет
"висеть" до тех пор пока объект не будет уничтожен - даже если внутри него
уже произошло явное переключение DS и "работает" объект уже в совсем другой
сессии... Это одна из основных причин, по которой нужно очень аккуратно
обращаться с командами переключения датасессии в методах любых классов.

Posted via ActualForum NNTP Server 1.3

Hi Aleksey!

> зачем он САМ переключает сессию

Для надёжности - чтобы код всегда исполнялся в известных условиях
окружения - при известных открытых (видимых) курсорах, стабильных установках
SET-ов и т.п.
Если бы такого переключения не было, то был-бы большой бардак :) Мы открыли
курсор - а его "вдруг" стало не видно, или сделали некоторую установку SET -
а она произвольно меняется от запуска к запуску...

> на ту, которая была активна при его создании

Не совсем так - это по началу методы работают в DS "породившей" объект -
если внутри метода произошло переключение DS - то потом уже методы объекта
будут работать в этой самой "другой" DS.

Posted via ActualForum NNTP Server 1.3