ASP Compiling?

[Victor]

I've got a website that is very fast. I just added a subroutine in the file global.asp
(global.asp is run each time any page is called). The subroutine determines the user's
country by comparing their IP address against a 6Meg Access database that converts IP to
country. It then sets a Session variable with the user's country.

After that, each time the subroutine is called it checks to see if that Session variable
is set. If it is, it exits the subroutine - without calling the Access database.

Regardless, I've noticed that my website is slightly slower than before.

Even though the Access database is only called once per session, does ASP compile
global.asp each time it is run, and is it slowing down because it is
compiling/establishing/whatever a connection to the Access database that it is not using
anyway?

(Hey, I know MS SQL is faster than Access! I'm trying to understand more about ASP,
that's all)

Thanks!

Vic

 

[Bob Barrows [MVP]]

I've got a website that is very fast. I just added a subroutine in
the file global.asp (global.asp is run each time any page is called).

Not really. Global.asp contains code for certain events:
application_onstart, application_onend, session_onstart and session_onend.
Where did you put your initialization code?

The subroutine determines the user's country by comparing their IP
address against a 6Meg Access database that converts IP to country.
It then sets a Session variable with the user's country.

So you used Session_onstart?

After that, each time the subroutine

Where is this subroutine located? in a ssi file?

is called it checks to see if
that Session variable is set. If it is, it exits the subroutine -
without calling the Access database.

Regardless, I've noticed that my website is slightly slower than
before.

Even though the Access database is only called once per session, does
ASP compile global.asp each time it is run, and is it slowing down
because it is compiling/establishing/whatever a connection to the
Access database that it is not using anyway?

Probably not, unless you've made the mistake of storing an ADO object in
Session or Application

 

[Mike Brind]

Not really. Global.asp contains code for certain events:
application_onstart, application_onend, session_onstart and session_onend.

Global.asp or Global.asa?

 

[Bob Barrows [MVP]]

Global.asp or Global.asa?

Oops. I kept mentally changing that to asa.

Victor, are you talking about an include file called Global.asp?

Show us the code so we can intelligently answer your question.

 

[Victor]

Not really. Global.asp contains code for certain events:
application_onstart, application_onend, session_onstart and session_onend.
Where did you put your initialization code?

No, you are describing global.ASA.

Global.ASP is MY code.

 

[Victor]

Oops. I kept mentally changing that to asa.

Victor, are you talking about an include file called Global.asp?

Show us the code so we can intelligently answer your question.

"global.asp".

Let me put it another way - when a .ASP page is called, I understand that the entire
page is compiled even if a subroutine or function or piece of code isn't used.

So, when an ASP page is COMPILED (NOT run), are database connections verified or
established even if it's not called?

For example, if I had this code:

If 1=2 Then ' ### This will never be called.becauae 1 <> 2.
' ### Connect to Access Database - this will never be called
strAccessDB = "/database/my6MegAccessDatabase.mdb"
accessdb = server.mappath(strAccessDB)
strconn = "PROVIDER=Microsoft.Jet.OLEDB.4.0;DATA SOURCE=" & accessDB & ";"
Set conn = Server.CreateObject("ADODB.Connection")
conn.open strconn
End If

Even though the above routine is never called, will it still be compiled, and a database
connection established, when the page it is on is called?

I suspect - and I'm looking for verification/documentation of this - that database
connections are established/verified at COMPILE time (NOT runtime). If that's the case I
may use a Server.Execute to only compile the code when needed.

 

[Bob Barrows [MVP]]

Let me put it another way - when a .ASP page is called, I understand
that the entire page is compiled even if a subroutine or function or
piece of code isn't used.

True

So, when an ASP page is COMPILED (NOT run), are database connections
verified or established even if it's not called?
No


For example, if I had this code:

If 1=2 Then ' ### This will never be called.becauae 1 <> 2.
' ### Connect to Access Database - this will never be called
strAccessDB = "/database/my6MegAccessDatabase.mdb"
accessdb = server.mappath(strAccessDB)
strconn = "PROVIDER=Microsoft.Jet.OLEDB.4.0;DATA SOURCE=" &
accessDB & ";" Set conn = Server.CreateObject("ADODB.Connection")
conn.open strconn
End If

Even though the above routine is never called, will it still be
compiled,
Yes

and a database connection established, when the page it is
on is called?

No. Compiling does not involve executing the code. Compiling just
translates it to machine-executable code. Think about why database
connection problems are only caught at runtime: never at compile time.
For example: supply a non-existant database in your connection string:
that will not be caught at compile time will it? Use your above if
statement to verify this.

I suspect - and I'm looking for verification/documentation of this -
that database connections are established/verified at COMPILE time
(NOT runtime).

No. Code is only executed at runtime (which is why it is called
"runtime").

If that's the case I may use a Server.Execute to only
compile the code when needed.

Depending on what the code is, that may be what you want to do anyways.

 

[Victor]

Victor wrote: :

No. Compiling does not involve executing the code. Compiling just
translates it to machine-executable code. Think about why database
connection problems are only caught at runtime: never at compile time.
For example: supply a non-existant database in your connection string:
that will not be caught at compile time will it? Use your above if
statement to verify this.

O.K., thanks Bob, this is exactly the info I was looking for!

Vic