8

It is possible to pass a parameter through server.execute?

Fx. I have in my site.asp an IF-scenario where I need functions.asp?a=something&id=123 executed. Is this possible?!

On site.asp:

dim id id = 123 if b = "hi" then server.execute("functions.asp?a=something&id=" & id) else response.write("No way dude") end if

On functions.asp

a = request.querystring("a") id = request.querystring("id") if a = "something" and cint(id) > 100 then response.write("Yes way dude") else response.write("No way dude") end if
Improve this question
3
  • What happens when you run your code? Commented Nov 30, 2011 at 10:57
  • Serverobject error 'ASP 0173 : 80004005' Invalid character in parameter-path in the MapPath-method --- Or something alike, it is in Danish at my screen :) Commented Nov 30, 2011 at 11:01
  • And without the querystring parameters included, what happens then? Commented Nov 30, 2011 at 11:06

4 Answers 4

Reset to default
5

You can't use querystring in Server.Execute, it's clearly mentioned in the official documentation.

What you can do is much better: you can directly access the variable id defined in site.asp inside functions.asp, and you can also declare and set another variable, a:

--site.asp:

dim id, a id = 123 a = "something" server.execute("functions.asp")

--functions.asp

if a = "something" and cint(id) > 100 then response.write("Yes way dude") else response.write("No way dude") end if

As it creates whole new "scripting environment" the executed file won't have access to the calling code properties, methods or variables, only to the global Request parameters, Session etc.

With this in mind, I fear the most simple way around is using Session variable to pass the value between pages:

Session("id") = 123 Session("a") = "something"

And then:

if Session("a") = "something" and Session("id") > 100 then response.write("Yes way dude") else response.write("No way dude") end if
Improve this answer
Sign up to request clarification or add additional context in comments.

9 Comments

That was what I thought as well. But it simply doesn't work. I have tried with unique variable-names to ensure that the variable isn't overwritten. But that isn't the case either.
Could it be because it is a server.execute inside a server.execute?
What you mean "doesn't work"? What exact error you get? Never tried nested Server.Execute but can't see any reason why it won't work.
Well the short version is, that the variable is empty :) And I have no idea why.. The answer you posted should work in my theory as well. I will use another way instead: functions() :)
If you want, post your whole code (or shortened version reproducing only the problem) and I'll take a look. It should work. :)
|
3

This question may be old and resolved, but the best answer doesn't mention everything, and there is information clearly posted on Microsoft.com about it:

Server.Execute Method

The following collections and properties are available to the executed ASP page:

  1. Application variables, even if they are set in the calling page.
  2. Session properties, even if they are set in the calling page.
  3. Server variables and properties, even if they are set in the calling page.
  4. Request collections and properties, even if they are set in the calling page. This includes Form and QueryString data passed to the calling page.
  5. Response collections and properties. The executed .asp file may modify HTTP headers. However, as with any .asp file, if the executed .asp file attempts to modify HTTP headers after it sends a response to the client, it generates an error.

So as you can see, there are 5 ways Microsoft suggests to pass variables through to a Server.Execute method. Before I saw this on Microsoft, the preferred method was Session, as the best answer suggests, since I saw this before the info on Microsoft.com. But after noticing that QueryStrings can be passed from the previous page, I would have to say this beats using Session for passing values. Session would be needed if your application required you adding variables to the executing page.

But passing variables, I would say QueryStrings, and it's easy to apply if your application allows the flexibility. I'm sure you know how to already use querystrings, but in the sense of using it for a Server.Execute method, you can simply do this:

Consider having ASP1.asp and ASP2.asp:

ASP1.asp includes: 

 Server.Execute("ASP2.asp")

ASP2.asp includes: 

 Response.Write Request("id")

When you call ASP1.asp?id=123 You will notice that ASP2.asp also see's the same Querystring passed to ASP1.asp, so it would write 123 on the response of ASP1.asp.

That's much less complicated than using a Session for the task.

Improve this answer

Comments

0

In short: YES, you can use QueryString values in conjunction with Server.Execute within an ASP.NET page or application.

You can pass dynamic variables in a QueryString argument assembled in the executing ASPX page (page1.aspx), as follows:

 Dim intExample1 As Int = 22 Dim strExample2 As String = "hello world" Server.Execute("page2.aspx?number=" & intExample1 & "&string=" & Server.UrlEncode(strExample2))

In this example, page2.aspx can then reference and use the following values:

 Request.QueryString("number") Request.QueryString("string")
Improve this answer

1 Comment

err, OP is asking about classic asp. asp <> aspx. whole other engine, as far as IIS is concerned.
0

Why not to use #include instead of server.execute?

I looked for a difference and found that in this particular case, using #include is the best solution: https://en.wikibooks.org/wiki/Active_Server_Pages/Server-Side_Includes#What_it_Does

You need some variables defined in parent page to be used in child, so your solution could be: 

dim id, a id = 123 a = "something" if b = "hi" then <!--#include file="functions.asp" --> else response.write("No way dude") end if

On functions.asp

if a = "something" and cint(id) > 100 then response.write("Yes way dude") else response.write("No way dude") end if

Advantages:

  • Simply act as it was the same page.
  • Use of disposal variables instead of Session variables.
  • Don't show internal variables in main URL.
Improve this answer

5 Comments

aren't includes hoisted like variable declarations though?
Please read "What it Does" section in the link above, it says "This allows you to import the contents of another document into the current one. This is extremely useful for reusing common blocks of ASP code and HTML", in this case variables declared in the first document will be available in the second. it's like you import the code itself and write it in the first document
but it's nothing like server.execute, which has its own memory space. also, try making a file called run.asp with content: start: <% if false then %><!-- #include file="yes.asp" --><% else %><!-- #include file="no.asp" --><% end if %>:end then in no.asp have response.write "no" and in yes.asp have <script language="Javascript" runat="server">for (var i=0;i<10;i++) {Response.Write ("yes, ");}</script> .. you will find that BOTH includes execute, regardless of the if conditional. So they are hoisted. and you have to break out of asp to do the include; doesn't work inline like you had
That's because you changed default language and used javascript instead of vb script, now try <% Response.Write ("yes, ")%> in yes.asp. this will run perfectly and it's equivalent to one file code. then try <% if false then %> <script language="Javascript" runat="server"> for (var i=0;i<10;i++) {Response.Write ("yes, ");} </script><% else %> <%response.write "no"%><% end if %> this last will print both, as you see there is no include.
But I use server.execute specifically so that I can switch to javascript, or activeperl, or some other language to execute something in separate memory space. I can already execute vbscript AND jscript in the same page in two different script tags, but not if one is inside an include. Don't you find that odd? Anyway, this isn't answering the OP's question

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.