Variable Scope (ASP.Net)

[Brian]

If i declare a module level oledbconnection with each
request for the page, the variable remains in scope? I get
open.executing error message on subsequent calls for the
page.

I assumed ASP.Net to be statless and all variables go out
of scope (except session, application) when making new
calls for a page?

Also, what is generally the best practice for creating
database connections for ASP.Net apps?

Thx

 

[Bin Song]

1. Using ViewState to maitain state of variables.
example ViewState("myVariable") = myvalue
2. Better create a data access tier.

Bin Song
MCP

 

[S. Justin Gengo]

Brian,

The variable does remain in scope. But you still need to close the
connection after a call to the database (depending on what type of code
you're executing).

e.g. A data reader needs to be closed, but a data adapter takes care of
closing the connection for you.

--
Sincerely,

S. Justin Gengo, MCP
Web Developer / Programmer

Free code library at:
www.aboutfortunate.com

"Out of chaos comes order."
Nietzche

 

[Brian]

Thanks for the immediate reponses...

I do immediately close the connection after execution. I
also have enableViewState = false on all the pages. I just
don't understand why the variable remains in scope on
subsequent calls?

Private Function GetDbConnection() As OleDbConnection

' Check whether connection already exists
If (m_objOleDbConn Is Nothing) Then ' Not yet!
m_strConnectionStr =
ConfigurationSettings.AppSettings("CONNECT_STR")
m_objOleDbConn = New OleDbConnection
(m_strConnectionStr)
m_objOleDbConn.Open()
End If

' Check the State
If (Not m_objOleDbConn.State =
ConnectionState.Open) Then
If (Not m_objOleDbConn.State =
ConnectionState.Closed) Then
m_objOleDbConn.Close()
End If
m_objOleDbConn = New OleDbConnection
(m_strConnectionStr)
m_objOleDbConn.Open()

End If

' Return Connection
Return (m_objOleDbConn)

End Function

 

[S. Justin Gengo]

Brian,

What type of database are you connecting to?


--
Sincerely,

S. Justin Gengo, MCP
Web Developer / Programmer

Free code library at:
www.aboutfortunate.com

"Out of chaos comes order."
Nietzche

 

[NoOne]

When you say module level do mean module as in VB module?

 

[Steve C. Orr [MVP, MCSD]]

The way most developers handle it is to put the connection string in your
web.config file, like this:
<configuration>
<appSettings>
<add key="DSN" value="Server=(local);Database=DBName;UID=sa;PWD="/>
<add key="OtherConnectionString"
value="Server=(local);Database=DBName2;UID=sa;PWD="/>
</appSettings>
</configuration>

Then in your code you can get the connection string like this:
Dim sConn As String = ConfigurationSettings.AppSettings("DSN")

Always remember to open you datababase connection just before you need it
and to close it as soon as you're done with it.
The built in ADO.NET connection pooling makes this very efficient.

 

[bruce barker]

module (static) level variables are shared between all threads, and live the
life of the application. for asp.net this is from the first page hit until
your site is unloaded. the use of module level variables in asp.net is not
thread safe, and you must use some sort of locking technique.

-- bruce (sqlwork.com)

 

[Brian]

Yes, i'm using .vb module variable to store my module
level variables.

do you know if this is documented in MSDN somewhere?

This seems strange to me. Wouldn't this defeat the purpose
of caching, session and application objects then? Wouldn't
this be a better approach to maintain state?

 

[Brian]

yes

-----Original Message-----
When you say module level do mean module as in VB module?




.

 

[bruce barker]

session state ties the global values to the browser cookie session, but you
are correct for application level global objects. you can implement your own
Application level cache by:

module myCache
shared Objects as new ArrayList()
end module

which is simular how the application cache is done. Session cache is done by
using context staorage, instead of global.

in vb6, module data was actually stored in thread local storage, while
vb.net module data is now global storage, which made it thread safe to use
in old asp pages. because asp.net is thread agile (the same thread is not
necessarily used to process the full page request) thread local storage is
useless.

in asp.net module variables should only be used to hold global data (shared
between all pages and concurrent requests). The connect string is a good
example. the application_start in global.asax is a good place to init module
varariables.

-- bruce (sqlwork.com)