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.

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