alternative for VB.NET module in c#?

[Milsnips]

hi there,

in my vb apps, i used to use a module where i stored global variables, but
in c# this doesnt seem to exist, what i want to do is create global
sqlcommand,sqlconnection variables that can be reused from anywhere within
the app.

please advise.
thanks,
Paul

[Marc Gravell]

This sounds like static properties, e.g.

public static class GlobalData {
public static string PrimaryConnectionString {get;set;} // details
not shown
}

3 additional thoughts:
* You might benefit from using the inbuilt pooling rather than keeping
an explicit SqlConnection open - particularly as complexity increases
(hence I illustrated with a connection STRING not a connection)
* Normal thread-safety rules apply to static members
* Of course, a better option (for connection strings) would might be
to use the ConfigurationManager classes and a config file

Marc

[Mark Rae]

"Marc Gravell" <ma**********@gmail.comwrote in message
news:e3****************@TK2MSFTNGP04.phx.gbl...

* You might benefit from using the inbuilt pooling rather than keeping an
explicit SqlConnection open - particularly as complexity increases (hence
I illustrated with a connection STRING not a connection)

Absolutely. The last thing an application should do is keep a permanently
open link to a database. This is especially true of web apps...

* Of course, a better option (for connection strings) would might be to
use the ConfigurationManager classes and a config file

Definitely.

[Milsnips]

Thanks for all replies.

My question was based for a Windows.NET c# desktop application, not a web
application so i assume its better to keep the connection open until the
user logs out of the application, or not?

As for the connectionstring, i'm using App.Config to store the string in
there and read it into the app during run-time.

regards,
Paul
"Mark Rae" <ma**@markNOSPAMrae.netwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

"Marc Gravell" <ma**********@gmail.comwrote in message
news:e3****************@TK2MSFTNGP04.phx.gbl...

>* You might benefit from using the inbuilt pooling rather than keeping an
explicit SqlConnection open - particularly as complexity increases (hence
I illustrated with a connection STRING not a connection)

Absolutely. The last thing an application should do is keep a permanently
open link to a database. This is especially true of web apps...

>* Of course, a better option (for connection strings) would might be to
use the ConfigurationManager classes and a config file

Definitely.

[Marc Gravell]

Even in a data-connected winform I would tend to use pooling and
tightly scoped connections. Smarter minds than mine have invested much
time to make pooling work effectively, but more importantly it means I
don't have to worry about issues with 2 parallel blocks of code
attempting to use the same connection at once.

Marc

[Milsnips]

Thanks for your reply mark.

In my little test app i created the following - a static public class called
DatabaseConnection with public properties "connection" and "command" which i
can access.

What i am playing around with is the following ideas: on each data call i do
the following:

1. call DatabaseConnection.Open();
2. ...here i do the SQL call(s)
3. call DatabaseConnection.Close();

is this an efficient way of programming or would it be better to open the
connection once on application start, then close the connection when the
application ends?

thanks,
Paul
"Marc Gravell" <ma**********@gmail.comwrote in message
news:u$**************@TK2MSFTNGP03.phx.gbl...

Even in a data-connected winform I would tend to use pooling and tightly
scoped connections. Smarter minds than mine have invested much time to
make pooling work effectively, but more importantly it means I don't have
to worry about issues with 2 parallel blocks of code attempting to use the
same connection at once.

Marc

[Kevin Spencer]

Open and close database connections as quickly as possible. The .Net
platform is architected to work and perform best in this way.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

"Milsnips" <mi******@hotmail.comwrote in message
news:%2***************@TK2MSFTNGP05.phx.gbl...

Thanks for your reply mark.

In my little test app i created the following - a static public class
called DatabaseConnection with public properties "connection" and
"command" which i can access.

What i am playing around with is the following ideas: on each data call i
do the following:

1. call DatabaseConnection.Open();
2. ...here i do the SQL call(s)
3. call DatabaseConnection.Close();

is this an efficient way of programming or would it be better to open the
connection once on application start, then close the connection when the
application ends?

thanks,
Paul
"Marc Gravell" <ma**********@gmail.comwrote in message
news:u$**************@TK2MSFTNGP03.phx.gbl...

>Even in a data-connected winform I would tend to use pooling and tightly
scoped connections. Smarter minds than mine have invested much time to
make pooling work effectively, but more importantly it means I don't have
to worry about issues with 2 parallel blocks of code attempting to use
the same connection at once.

Marc

[Marc Gravell]

on each data call i do the following:

It really comes down to how your code is situated. Generally, the
pattern would be
using(connection = [create]) {
[open]
[do something]
[close]
}

As long as pooling is enabled, this doesn't actually close the
connection; it returns it to the pool. Chances are that next time you
open a connection you will get the same underlying connection
(although almost certainly a different .Net wrapper object).

The "do something" could be a single operation or multiple operations,
but not usually the entire app; the lifetime of a connection should be
tightly scoped as far as possible. Again, I stress that in many common
scenarios you actually end up achieving the same thing - i.e. a single
connection that is re-used, but this approach is usually preferable -
more efficient and less chance of bugs due to re-entrancy / threading
etc (attempting to use the same connection twice at the same time).

Marc

[Jon Skeet [C# MVP]]

On Apr 17, 11:53 am, "Kevin Spencer" <[e-mail]>
wrote:

Open and close database connections as quickly as possible. The .Net
platform is architected to work and perform best in this way.

This is certainly the case for ASP.NET etc which will make use of the
pooled connections in a useful way.

I doubt that it will actually make any difference on a client app
which would only ever use one connection at a time anyway. I could be
wrong, and I'd be interested to know if so :)

I'd still recommend opening and closing the connections as quickly as
possible anyway, for consistency when changing whether you're coding
on ASP.NET or a thick client.

Jon

[Mark Rae]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@l77g2000hsb.googlegr oups.com...

I'd still recommend opening and closing the connections as quickly as
possible anyway, for consistency when changing whether you're coding
on ASP.NET or a thick client.

Especially if you have a DAL which can just be dropped into either type of
project unchanged... :-)

[Ravichandran J.V.]

Use a class

public class DataVariables
{
public DataVariables(string connstr)
{
con=new SqlConnection(connstr);
}
private SqlConnection conn;
public SqlConnection Conn
{
get{
return conn;
}
}
}

etc.

with regards,
J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com

*** Sent via Developersdex http://www.developersdex.com ***