><< PMFJI-
>
>No problem...
>
>
><< maybe I don't understand the problem, but couldn't you get away from session << vars altogether by implementing a generic session
><< class that stores all this stuff for you in data files? What could this 3rd << party solution do that you couldn't write yourself?
>
>To the best of my understanding, classes instanciated on IIS do not persist across pages. Therefore, if you were to build a class that saved session information, you'd have to build it so it read from a database, text file or the registry.
That is what I suggested (in data files- ie tables).
>This is certainly possible, but I, like most developers I know, am pressed for >time.... :-)
You mean you are worried about processing time, or development time? Either one should not be an issue. Build a single table with a threadid and a memo field. Write a routine that creates a session by adding a record with the thread id, and adding whatever session variables to the memo field like VFP does in scx and vcx files. All you need to do is write a parser that knows how to look for the names of and retrieve the values of the session variables given the threadid and the name of the sesion variable. WWWC has a session class that works mostly like this...
>Unfortunately, the real crux of the problem is, again, a flaw in an M$ product... Oh well, we've worked through these before... (and will again)
What is the flaw?
Erik Moore
Clientelligence