Hi Rick,

Recently I've been getting error reports that look like this on my production server, which is running in COM mode. (Obscuring some of the fine details...)

Processing Error - .../publishcatalog.r3?

<pre>
      Error: 1937
    Message: Procedure file 'c:\users\rkaye\appdata\local\temp\wwhttp.fxp' is not found.
       Code: receipt

    Program: destroy
    Line No: 285
     Client: 203.45.249.177
Post Buffer: &jsSubmitValue=&saleselected=270920+&btnPublishSubmit=creategroup
</pre>
Exception Handled by: R3process.OnError()

This is confusing the heck out of me as the app doesn't run under my user context, although I do remote into this server on occasion. I also don't understand why it would try to delete a framework FXP when it's all embedded in the EXE? It does run as a specific domain account, and that account wouldn't have access to my local profile temp folder. Finally, I am also unable to reproduce this in my development environment. IOW the page that generates the production error behaves as expected so I never hit the error. I'm looking for better ways to trap this so I can figure out what's not happy in the production environment. In the meantime, I thought I should check with you for suggestions. lDebugMode is disabled but I was unsure as to whether or not it was a good first step or a last resort.

TIA

The filename is what's compiled into the EXE with Debug information - doesn't mean the file is there, but that's the record that the EXE has of where the file comes from. I wonder if for some reason wwhttp.prg isn't included in the project and then not actually compiled into the EXE?

Destroy is the method of some object destructor firing, most likely the parent object of the Receipt() method.

Error information isn't always accurate in compiled applications, especially as they relate to object unwinding, due to inheritance and composition.

+++ Rick ---

I double-checked the project and wwHttp is included so my guess is that message is a bit of a red herring. However, there is an object invoked by this page which does some API call stuff and it does have a destroy method. In that method I have some cleanup code that releases several WW PRG procs. I don't know why this has been happening lately as I don't think I've changed that cleanup code in ages but I'm going to comment out the RELEASE PROCEDURE bits and see if that's the cure.

Thanks for the pointers.

Yes - make sure you don't release Web Connection libraries in your code. Release procedure should only ever be used on loose files outside of an EXE otherwise you run into problems with the embedded files potentially getting corrupted.

+++ Rick ---

Right. I built this class in a way that allowed me to unit test it as a stand-alone object as well as being invoked in an application context. I will update to make sure those release calls only happen outside of the application environment.

FWIW, it's a bad idea to add lifetime management directly into a class unless the class tracks whether something it loads has already been loaded.

In general I think it's a bad idea to unload code at runtime. The exception is code that needs to be unloaded and reloaded (like Templates that could change after they have executed).

Other than that I see no reason to ever unload anything. If you need to keep your environment from getting too overloaded add a hot key to do:

CLEAR ALL
CLOSE ALL
RELEASE ALL
CLEAR PROGRAM
CLEAR

I pretty much run this before I start running any PRG or application locally. I have it tied to a F4 macro key.

So it's F4 followed by Launch()... You can also add code to the end of the Web Connection Mainline that closes out everything it can.

For example the bottom of my sample wcdemomain.prg looks like this:

*** Set developer environment clean
*** THIS IS OPTIONAL - Modify to your needs
SET SYSMENU ON
SET DEBUG ON
SET DEVELOP ON
SET STATUS BAR ON
SET TALK ON
CLOSE DATA

RELEASE ALL EXCEPT llAutoRestart
 
IF llAutoRestart
   LiveReloadShutdown("DO wcDemoMain.prg")
ELSE
   *** USE THIS FOR DEBUGGING OBJECT HANGING - fires all outstanding DESTROY()
   *** and you should see which objects are hanging
   *SET STEP ON  
   CLEAR ALL   
ENDIF


IF Application.StartMode = 0
   ACTIVATE WINDOW COMMAND
   SET RESOURCE ON
ENDIF

RETURN

This pretty much clears everything everytime i shut down the application - except if there's something stuck with circular references in which case the F4 key takes care of that.

+++ Rick ---

I've got a reset the environment util that I use in dev. Generally I've got cleanup associated with the application lifetime as opposed to what I've done with this particular class. I should have thought of those release calls but I was more focused on being able to test it thoroughly without having to load the application environment. And, of course, I'm still pretty fresh to this web environment so will no doubt find plenty more rookie mistakes to make along the way. I've pushed an update and am hopeful this puts an end to the error.

Thanks again.