>
>A total shot in the dark but, could this have something to do with loss of state (DCOM & repeated calls to the object). The DLL is being accessed through the network right?

Possible, but my inability to prove my code was simply a pathing issue involving Foxtools. I'm still at a loss to explain the behavior that did occur. I would've thought that if it were the case, problems other than the ones that did occur would arise.

FWIW, it's (the error that started this) some sort of OLE error that's occurring on one box, in a Problem...er...PowerBuilder application that's utilizing my DLL. The method before the If...Then statement in the script was the one that was raising the OLE error. However, now that we've shown that the method can be called from another client without creating the same error. It reduces the possibility that it's a server side problem. Still, I've just been given the task of completly accessing the object via a script, storing the data cand calling the methods they do.



>For testing, I would try raising the error with COMRETURNERROR() in the Error method of the class and also writing the variable contents to a uniquely-named file with LIST MEMORY TO FILE.

I intially had designed it that way. However, a change in the specs required that the caller know the nature of any internal error. At this point (I've been working on this on and off for over a year and a half), I'm sick of the project and only want to deal with it as necessary. Thanks for the suggestion, though.

>PS Answering to a meaningless title thread, against my better judgment ;)

I would've given it a meaningful title but I was: A. Lazy; B. Couldn't figure out how to summarize the problem because of its complexity; or C. So frustrated that I wasn't thinking clearly. Pick one or more.

Oh, and send Nancy my way to give me a good whack with one of her trouts.:-)