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