views:

323

answers:

2

What setting might be missing or misapplied that would cause the same code that works on an IIS 6.0 server to fail on an IIS 5.1 server?

I've inherited this large Classic ASP application. It "caches" a series of files with funcitons in them using the ExecuteGlobal command. On both server, the command executes without error. However, when the application later tries to reference the functions that were 'cached', IIS 6.0 seems to work just fine while IIS 5.1 acts as though those functions never existed and I get errors to that effect.

The 5.1 system is for testing purposes on an XP Pro box. The 6.0 is our production system on Windows 2003.

It's taken a long time to isolate the problem (identical code failing in test but working in production) to this code. Setting up another server isn't an option unfortunately (budget restraints - no money to pay the support people or to rent space where all servers must be physically located - military installation).

What directions have I missed looking into?

A: 

Hi, David!

Are "caching" and "using the functions that were cached" happens while processing the same HTTP request?

If the answer is "yes", then I've got no ideas, and I sincerelly hope someone else will answer your question.

If the answer is "no", then I'm pretty sure your problem is you "cache" the function into a different VBScript execution context.

Try (on the test server, of course :-) adding the following 2 lines in a file that defines the functions:

Dim g_FunctionsLoadedOK
g_FunctionsLoadedOK = "OK"

and the following line just before you're using the function:

if( Eval( "VarType(g_FunctionsLoadedOK)" ) <> vbString then
    ' Then you're sure there's no 'g_FunctionsLoadedOK' string variable defined in this VBScript execution context,
    ' so maybe you should reload the cached functions, or do something else..
end if

P.S. Unless the system you're dealing with is really large, why not use <!-- #include file="MyFile.inc" --> instead of that "ExecuteGlobal" approach?

Soonts
Thanks for the suggestion. The include methodology is what they used to do until the page got huge so the includes were replaced by including a routine that was supposed to simulate the "require_once" PHP functionality.
David
This won't help youre case but replacing server side includes for executeglobe seems to me a bad idea. Not only will you loose all debuging information, peformance will also suffer badly.ASP files are compiled to bytecode and then stored in a cache. Having a big application with a lot of includes doesn't slow down the application. We run a huge app with from one single asp file (using urlrewriting) with a lot of includes and it works like a charm.Execute, executeglobal and eval are however rally slow because the need to compile the string to bytecode on every call.
Joost Moesker
I would *love* to dispatch the "fake a require_once" code to the recycle bin. I think the original programmer did it just because he liked it in PHP. It's becoming increasingly apparent to me that I'm going to have to come up with a solution that eliminates the 'ExecuteGlobal' part.
David
A: 

Can you post the code for the fake ExecuteGlobal stuff, it might be possible to refactor it to get it to do what you want using Includes so that you don't have to break anything. Failing that a bit of find and replace might be needed :)

Pete Duncanson
Turns out that things are not what they seem. While the error I got made it look like the cached function wasn't defined, putting in some debug code earlier in the VBScript part of the page (the error is happening in Javascript) showed that the function indeed WAS defined and 'remembered'. I *did* start trying to replace the 'require_once' stuff with INCLUDEs but that has other problems due to the differing environments. I got a reprieve, though. My boss is telling the "higher ups" that we need a true test environment and can't keep "winging it".
David