Hi Dragan,

So I wrote a utility program that I could call from a few points and I wrote out to a file all the datasessions and tables in each datasession and form info etc.

Guess what: when the code fails, the current datasession (from SET("datasession")) is not the datasession of the form that I am calling the code from. So something is changing the datasession. It should not be my code as I avoid changing datasessions like the plague. I also don't use session objects on their own (I honestly did not even know they existed until Al Doman pointed it out - could have used them before).

The weird behaviour I found is that the datasession being pointed to is like a "phantom" of the correct datasession but it is missing all the views from the correct one. e.g. if the correct data session has 10 tables open and 5 views, the "phantom" one has just the same 10 tables with no views. It's like the framework (VMP) is opening up a session object for just the tables. The weird thing is that it is not consistent either a) on my desktop or b) every time the form in question is fired. If it was something built into the framework, then I would expect that these phantom sessions would exist all the time in every place.

I think VMP had something in it where it was supposed to open all tables a 2nd time in the default data session such that tables always stayed open - for speed so that tables are not constantly being opened and closed on the network. Hopefully some other VMP developer (Mike Yearwood?) would know more about this as postings on the VMP site are pretty slow to get responded to.

It might be that I have to start passing the datasession id to each procedure as a stop-gap measure. This also means that I have to change code such that the data session and the usual primary key are worked up and passed another way as the call is failing on the very first line where the primary key is being passed in e.g. this code fails when calling the data function:

llDataOkay = GetAppData(v_Apps.App_ID)

so I probably need to work up the values and pass them another way (array or object) to the procedure.

but I would rather just fix the real problem or its bound to raise its ugly head at some other point and bite me in the rear.

Albert






>>Wrapper class: I assumed not data environment change would happen with a wrapper class made from a custom object - there is no form DE to fire up and get in the way right? As well, have used the wrapper class for about 6 months with no problems but this was *before* adding in code that fires from an EVALUATE() statement. That is, before this point, the classes would work fine for firing up Word and creating a document in Word but now that I have started to work in code that reads data from the current form to stuff into Word, I get the errors happening for the EVALUATE() portions of the code.
>
>Any object's code will run in the datasession which was active when it was instantiated. Check the datasession from within your global object's code.
>
>I had this problem several years ago when I called stuff from one of those global singleton objects, while trying to avoid code repetition. But guess what, some of that was dependent on datasession (i.e. expected certain aliases to be present) and we ended up reorganizing code so that the globals either handle no tables, or tables that are open in their own datasession, or have a datasessionID of the caller passed as a parameter.
>
>In most of the situations, however, such utility objects are instantiated when needed (or even when not, but need to be available as an option). The cost of instantiating a non-visual object is not high, and a cost of repeatedly instantiating an object is even lower, because of fox's caching. So many of those things that require a common datasession with the caller are simply instantiated by the caller.
>
>The head scratcher is the question why does it work in your environment, then?