server.execute vs. #INCLUDE

Results 1 to 2 of 2

Thread: server.execute vs. #INCLUDE

  1. #1
    Join Date
    Dec 1969

    Default server.execute vs. #INCLUDE

    Greetings, <BR><BR>We currently use a number of #INCLUDE files, but their execution is conditional -- have long case statements that #INCLUDE different files depending on what&#039;s what. In the research I&#039;ve been doing everyone has been saying we should be using Server.Execute() instead, and on the face of it, it seems to make sense. But now that I&#039;ve been experimenting I find that Server.Execute() runs the called file in its own memory space, and precludes any sharing of variables or objects. Am I right about this, or is there something I can be doing (other than writing everything to the Session object) to share these values/objects? The documentation on this function seems thin, at best... <BR><BR>Thanks. <BR><BR>jc

  2. #2
    Join Date
    Dec 1969

    Default Server.Execute nearly useless... you have found out.<BR><BR>On top of everything else, it&#039;s performance stinks. Much much slower than #include&#039;s. <BR><BR>I presume you realize that your #include&#039;s aren&#039;t *really* conditional. I think that&#039;s what you meant when you said "their execution is conditional."<BR><BR>So all you really have is this moderately large chunk of VBScript code that is presented to the compiler after all the #include&#039;s have occurred. And if that page stays "hot" then the compile won&#039;t need to take place again, and it won&#039;t much matter how big it is. (And if the page does *not* stay hot--if it&#039;s only used a few times an hour, say--then does it really matter if it take a couple of milliseconds to compile it again?<BR><BR>Incidentally, Server.Execute *DOES* share the Request and Response objects with your main page, for all the good that does.<BR><BR>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts