Hi Hank,

Back after a long week away at a course...

It did turn out to be the datasession ID. In this case, using the data in the datasession was just a "convenience" as I could have pulled the data from the tables. It seemed cleaner to just rewrite the procedures to pull the data from the tables instead of checking/setting datasession ID. Thanks for the heads up on what was going on as I did not know that things could change based upon where the code was firing (class vs. prg code etc). This is not an on-going problem with this app so easiest to just work around where the data gets fetched from then to work in something to the overall system.

Thanks again,
Albert


>Perhaps they are all being created with the default datasession. We give each class instance a name (this.name = "myclass:"), which makes finding the datasession in the SET dialog easier.
>
>>Interesting...did not know that. I have a lot of functions in a .prg that are "lookup" functions (look up a name or company name etc) so they can be used in reports or queries etc. But usually these are looking up directly from the tables so maybe that's why I have never run into anything yet.
>>
>>Thanks,
>>Albert
>>
>>>Hi Albert,
>>>
>>>when you access a class from a class, there's no issue. When you are in a class, then call a prg, and that accesses a different class, you can run into issues. Save the DSID and reset it in the prg. Because this is done so often, we created a prg set_dsid() that returns the DSID when called with no parameter, and when passed a parameter sets the DSID if that is not the current one.
>>>
>>>Hank