>Sergio,
>
>hm, it depends on what level one is working in the program. On surface you will not need it. But as soon as you need a clearup or a nice errorreporting or a classfactory one is happy to do it.

All I am saying is that I simply always felt better doing

oBO.InsertSomethingIntoSomeTables(SomeValues)
*or
oRec = oCBO.GetRecLayout(pKey)

rather then then

set datasession to B
replace ...
scatter name oRec  
set datasession A
do things with oRec

I see second aproach as sort of 'intrusive'. Sort of like jumping in and out of windows rather then using normal entrances/exits :)

I saw some listener code which did simillar (second) scenario with frx session. And it looks kind of wrong and unsafe to me.

As it stands now listener keeps frx datasession as a number and have couple of methods to set and reset it. That is what I believe causes bugs like this. It is very easy to break this fragile balance in subclass code.

Imho, oBaseListener.FRXDataSession instead of holding number, should be holding object reference to a fully blown session object acting as a sort of 'server', rather then us having to *tresspass* with set datasession to ... and then get eventually get caught with the bug
and with dangling datasessions lingering arround.

Instead, whatever info is normally needed from frx session, could be obtainable by doing it normal OOP way, by calling methods that return info/values.

From within listener we should be able to call
this.oFRXSession.GetFrxRec(nFrxRec)
this.oFRXSession.GetThisOrThat(...)
etc

Destroy method of listener could safely release frx session object and reference kept in that property and nobody would ever get into any trouble with it.


That is just my opinion.

Sergio

>
>Update:
>
>I agree that it should be better wrapped, so that for each cruel datasession the listener opens a specialiced object should deal with. So one would never need to switch.
>Agnes
>>Hi Agnes,
>>
>>Somehow I never liked idea of setting session directly in code.
>>
>>

SET DATASESSION TO X

>>
>>You were forced to fix your problem this way, but maybe just maybe somewhere
>>down below (in listeners) problem is caused the same way.
>>
>>I Always tought that this command should be used very restrictively.
>>I was actually surprised when I saw it to be used by MS as part of actual listener code.
>>Imho (way I understood it) session should be threated as an object, and communicate with environment just like any other object. (I use session object extensively, so maybe that is why I see it this way)
>>
>>To me 'SET DATASESSION TO X' sounds exactly as good as 'SET FORM A TO B'
>><g>
>>
>>Recently, I build one specific update listener which was designed to communicate/parse records directly to my session object via obj. reference held in one listener property.
>>But that simply refused to work way it should, no error would flash but sessions would got all messed up. Aldough it could be that I overlooked something (I prefer glitch to be on my side!), I tend to believe that problem could be caused by listener sort of 'playing rough' with datasessions, and messing up active sessions on it's own (as Cathy and You experienced/reported as well). I bypassed problem for now but I am not satisfied with my solution because of that, and will have to design it little bit differently.
>>
>>That SP3 <g> could actually have hands full of very desireable fixes
>>if it ever comes to us.
>>Let's just hope it happens.
>>Sergio
>>
>>
>>>Hi All,
>>>
>>>this is a solution, I need no help on it.
>>>A related problem might be.
>>>http://cathypountney.blogspot.com/2007/12/gotcha-dangling-datasession-left-after.html
>>>
>>>Problem:
>>>I've created Hooks that I used via XML Memberdata on a listener based report.
>>>After one report run I was unable to edit my report. (File is used)
>>>After the report an Datasession UNKOWN was left. Within those report the frx file and several helpfiles where open.
>>>
>>>Analysis:
>>>I've played around with my hook to figure out where it fails, but without success. Finaly I put a Return False in its init, but the problem remains.
>>>If the XML was empty, all was fine.
>>>I debugged through the listener (I have changed the one shipped with VFP due to its problems, it craches with my language settings).
>>>I figure out that if there was data in a XML Memberdata a extra Object of class fxmemberdatascript::listener.vcx would be instantiated.
>>>This class is playing around with datasessions. A closer look shows that it does not reset the datasession.
>>>
>>>Solution
>>>I've searched all occurenses of SET DATASESSION in the methods of the class and wrapped the code with
>>>

>>>LOCAL;
>>> liSession
>>>
>>>liSession = SET("Datasession")
>>>
>>>SET DATA...
>>>....
>>>SET DATASESSION TO (m.liSession)
>>>

>>>
>>>If the last command in the orignal method was a reset to some DATASESSION, I've put a comment on it.
>>>Like this snippet from ProcessDynamicMethodScript
>>>

>>>...
>>>      FINALLY
>>>*!*	         IF m.toListener.FRXDataSession > 0
>>>*!*	            SET DATASESSION TO (m.toListener.FRXDataSession)
>>>*!*	         ENDIF
>>>      ENDTRY
>>>   ENDIF
>>>ENDIF
>>>
>>>SET DATASESSION TO (m.liSession)
>>>

>>>
>>>Now you need to recompile the app, place it where it belongs (check _REPORTOUTPUT) and need to figure out how to ship that particular application with you main application. What a waste of lifetime.
>>>
>>>
>>>Agnes