Beginner ?

[AussieRules]

Hi,

I have a asp.net project I am building in vstudio.net 2003

I have done VB.net projects, but this is my first asp.net(vb.net behind
code)

In a vb.net project I can have a global.bas file, define some public vars,
and then access them within any vb form. I do this with my sqlConnection
object.

I want to do the same with my asp.net app. That is connected once, and use
that connection accross all my asp.net forms

I have in the global.asax.vb file, a publicly declared sqlConnection object.

Within the global.asax.vb I have some functions that use the sqlConnection,
and they work fine.

My problem is that in an asp.net form, the sqlconnection object(declared in
the global) file seems to not be valid.

Is this even possible to do, or does every form have to have its own
declared vars, which would mean I would have to manage my SQL connection on
every form

hope that makes sense

thanks

 

[Steve C. Orr [MVP, MCSD]]

Do not use the same connection throughout your site. This would be very bad
and would limit your scalability severely.
ADO.NET has built in connection pooling.
Therefore you should open a database connection just before you need it on a
page, and close the database connection as soon as possible. The connection
pooling makes this very efficient.

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 from each page you can get the connection string like this:
Dim sConn As String = ConfigurationSettings.AppSettings("DSN")

 

[Kevin Spencer]

An ASP.Net application is so unlike an executable application that you're
going to have to rethink your entire architecture. The reason for this is
that an executable application exists for the life of the application.
Memory is persistent throughout the life of the application. ASP.Net is a
web application technology. HTTP is stateless, which means that when an
ASP.Net Page is requested, it happens "in a vacuum" so to speak. The web
server has no memory of previous requests, neither of the current Page, nor
of any others. It instantiates the ASP.Net Page class when it receives the
Request. The class exists on the server just long enough to produce the HTTP
Response, which sends the dynamically-generated HTML document to the
browser. Then the class is unloaded.

For this reason, ASP.Net includes some cachinig features that permit the
developer to persist data in memory for longer than a single Page
Request/Response interval. These include the Application, Application Cache,
and Session, to name a few. Data stored in the Application or Application
Cache are truly global; it can be accessed from any Page Class in the
Application Domain, by any client. Session State is confined to any Page
Class instantiated by a given client for the duration of the client Session.

In addition, we're talking about a client-server application with the
potential for a whole slew of clients. For this and some other reasons,
caching ADO.Net objects in any caching mechanism is generally not a good
idea. This is why Connection Pooling was incorporated into the .Net
platform. You can open and close a Connection, but it remains in the
Connection Pool for a period of time, and if another class needs to open a
Connection, it is retrieved from the Pool rather than being re-instantiated,
re-initialized, etc. As long as it uses the same Connection String, it can
be pulled from the Connection Pool quickly and inexpensively.

Therefore, I would recommend that you only store your Connection String
persistently (usually this is in the web.config file), and write your code
to open a fresh Connection with each Page that needs one. Typically, a class
of static Methods can provide all the database-connective functionality you
need. For our company, I created a Class Library of static Database Methods,
which I can use in any application we create, web-based or executable.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.