By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,495 Members | 1,252 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,495 IT Pros & Developers. It's quick & easy.

Programming - Best Practice

P: n/a
Hello.

I have been teaching myself .NET over the last few months and have had
some success. I would like to ask a question though...

A number of examples I have followed have the following in their
finally statement

Try
......
Catch
......
Finally

If (Not IsNothing(dbConn)) Then
dbConn.Close()
End If

End Try

Will my data connection always close using this method or should I
just use dbConn.close?

I have a program that seems to be holding onto its connection - am I
missing something?

Feb 16 '07 #1
Share this Question
Share on Google+
51 Replies


P: n/a

"bigHairy" <mt*********@gmail.comwrote in message
news:11**********************@m58g2000cwm.googlegr oups.com...
Hello.

I have been teaching myself .NET over the last few months and have had
some success. I would like to ask a question though...

A number of examples I have followed have the following in their
finally statement

Try
.....
Catch
.....
Finally

If (Not IsNothing(dbConn)) Then
dbConn.Close()
End If

End Try

Will my data connection always close using this method or should I
just use dbConn.close?

I have a program that seems to be holding onto its connection - am I
missing something?
If you just use dbConn.Close(), you'll get an exception if the connection in
question is not open.
The code in finally first checks to see if dbConn is an empty reference (no
active connection), and only attempts to close it is there is an active
connection to close.
As code in the finally block is "guaranteed to execute", the code you posted
closes the connection *if* it is open.
The question is, what makes you think the connection remains active after
this code executes?
Feb 16 '07 #2

P: n/a
Thanks for your prompt reply, I appreciate the help.

I am currently in discussions with a 3rd party data provider as there
seem to be timeout issues using a linked SQL Server with a Progress
Database. There are suggestions that it may be our program leaving
connections open but I can find no evidence of this - thought I would
check that I am using the best practice for closing these connections
as a first port of call before I go investigating the rest of the
process.
Feb 16 '07 #3

P: n/a
You could use something like this to close your connection:

If objConn.State = Data.ConnectionState.Open Then
objConn.Close()
End If


"bigHairy" <mt*********@gmail.comwrote in message
news:11**********************@m58g2000cwm.googlegr oups.com...
Hello.

I have been teaching myself .NET over the last few months and have had
some success. I would like to ask a question though...

A number of examples I have followed have the following in their
finally statement

Try
.....
Catch
.....
Finally

If (Not IsNothing(dbConn)) Then
dbConn.Close()
End If

End Try

Will my data connection always close using this method or should I
just use dbConn.close?

I have a program that seems to be holding onto its connection - am I
missing something?

Feb 16 '07 #4

P: n/a
On Feb 16, 11:07 am, "Zim Babwe"
<zimba...@doyoureallythinkthisisreal.comwrote:
You could use something like this to close your connection:

If objConn.State = Data.ConnectionState.Open Then
objConn.Close()
End If

"bigHairy" <mthomas1...@gmail.comwrote in message

news:11**********************@m58g2000cwm.googlegr oups.com...
You could call Dispose instead of Close. Dispose will not throw
exceptions. If you're using VB 2005 the Using keyword can clean up
the code quite a bit as well.

Feb 16 '07 #5

P: n/a
Hi,

AS you ask for Best Practice than you don't definitly not need a test to see
if your connection is open.

You control your program, so you know if it is open or not and can close it
therefore at the right time without any error.

Cor

"Zim Babwe" <zi******@doyoureallythinkthisisreal.comschreef in bericht
news:Oa*************@TK2MSFTNGP04.phx.gbl...
You could use something like this to close your connection:

If objConn.State = Data.ConnectionState.Open Then
objConn.Close()
End If


"bigHairy" <mt*********@gmail.comwrote in message
news:11**********************@m58g2000cwm.googlegr oups.com...
>Hello.

I have been teaching myself .NET over the last few months and have had
some success. I would like to ask a question though...

A number of examples I have followed have the following in their
finally statement

Try
.....
Catch
.....
Finally

If (Not IsNothing(dbConn)) Then
dbConn.Close()
End If

End Try

Will my data connection always close using this method or should I
just use dbConn.close?

I have a program that seems to be holding onto its connection - am I
missing something?


Feb 16 '07 #6

P: n/a
The issue here has nothing to do with whether or not the database connection
is open. It is to do with whether or not the database connection object has
been instantiated.

You will probabaly note that the 'examples' have the dbConn variable
declared before the Try. This means that the dbConn variable is 'scoped' so
that it is available to the Finally block.

With both the SqlConnection and OleDbConnection classes, calling Close on an
object of those types that is not open will NOT cause an exception. However,
if you call Close on an object of those types that has NOT been instantiated
(Is Nothing) then an exception WILL be thrown.

In the Try block, if an exception is thrown before dbConn is instantiated
(let alone opened), the logic will 'jump' directly to the Catch block and
then fall through to the Finally block. At this point dbConn would be
Nothing and a call to dbConn.Close would fail. The conditional execution of
dbConn.Close handles this situation.

Because the code Finally block is executed regardless of whether an
exception was thrown or not, having the conditional execution of
dbConn.Close means that you do not need to worrying about closing the
connection in either the Try or Catch blocks.
"bigHairy" <mt*********@gmail.comwrote in message
news:11**********************@m58g2000cwm.googlegr oups.com...
Hello.

I have been teaching myself .NET over the last few months and have had
some success. I would like to ask a question though...

A number of examples I have followed have the following in their
finally statement

Try
.....
Catch
.....
Finally

If (Not IsNothing(dbConn)) Then
dbConn.Close()
End If

End Try

Will my data connection always close using this method or should I
just use dbConn.close?

I have a program that seems to be holding onto its connection - am I
missing something?
Feb 16 '07 #7

P: n/a
I didn't think that you could even leave a connection open.

it's one of my biggest complaints about ADO.net; I used to use @@SPID
similiar to sessionID in ASP in order to build some simple apps...

but now there is nothing like that in .NET from what I understand

I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?
like I'm being serious and honest here.

Thanks

On Feb 16, 12:04 pm, "Stephany Young" <noone@localhostwrote:
The issue here has nothing to do with whether or not the database connection
is open. It is to do with whether or not the database connection object has
been instantiated.

You will probabaly note that the 'examples' have the dbConn variable
declared before the Try. This means that the dbConn variable is 'scoped' so
that it is available to the Finally block.

With both the SqlConnection and OleDbConnection classes, calling Close on an
object of those types that is not open will NOT cause an exception. However,
if you call Close on an object of those types that has NOT been instantiated
(Is Nothing) then an exception WILL be thrown.

In the Try block, if an exception is thrown before dbConn is instantiated
(let alone opened), the logic will 'jump' directly to the Catch block and
then fall through to the Finally block. At this point dbConn would be
Nothing and a call to dbConn.Close would fail. The conditional execution of
dbConn.Close handles this situation.

Because the code Finally block is executed regardless of whether an
exception was thrown or not, having the conditional execution of
dbConn.Close means that you do not need to worrying about closing the
connection in either the Try or Catch blocks.

"bigHairy" <mthomas1...@gmail.comwrote in message

news:11**********************@m58g2000cwm.googlegr oups.com...
Hello.
I have been teaching myself .NET over the last few months and have had
some success. I would like to ask a question though...
A number of examples I have followed have the following in their
finally statement
Try
.....
Catch
.....
Finally
If (Not IsNothing(dbConn)) Then
dbConn.Close()
End If
End Try
Will my data connection always close using this method or should I
just use dbConn.close?
I have a program that seems to be holding onto its connection - am I
missing something?

Feb 16 '07 #8

P: n/a
On Feb 16, 3:00 pm, pfc_s...@hotmail.com wrote:
I didn't think that you could even leave a connection open.

it's one of my biggest complaints about ADO.net; I used to use @@SPID
similiar to sessionID in ASP in order to build some simple apps...

but now there is nothing like that in .NET from what I understand

I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?

like I'm being serious and honest here.

Thanks
Hi,

What made you think you couldn't leave a connection open?

Brian

Feb 16 '07 #9

P: n/a
uh a half dozen MS press books???
uh a half dozen MS press books???
uh a half dozen MS press books???
get a spid; get another SPID.

DO THEY MATCH?

because if they do then I'll accept a written apology from Microsoft
and new editions of their books that are CORRECTED.
On Feb 16, 1:48 pm, "Brian Gideon" <briangid...@yahoo.comwrote:
On Feb 16, 3:00 pm, pfc_s...@hotmail.com wrote:
I didn't think that you could even leave a connection open.
it's one of my biggest complaints about ADO.net; I used to use @@SPID
similiar to sessionID in ASP in order to build some simple apps...
but now there is nothing like that in .NET from what I understand
I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?
like I'm being serious and honest here.
Thanks

Hi,

What made you think you couldn't leave a connection open?

Brian

Feb 16 '07 #10

P: n/a
I think you misunderstood what the MS-Press books were saying.

The opening and closing of ADO.NET connections, along with the implications
this has on the connection pool, can catch people by surprise.

The general rule for your code is open / execute / close - this is how best
you're able to work with the connection pool. There's nothing stopping you
from doing other things though - like holding connections open, or any of a
dozen other (bad) things.

Be aware that, under the hood, open / close don't actually open or close
database connections. IT's more "Check out from pool", "Check back into
pool". It's up the pool as to when the connections are actually opened and
closed.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

"PFC Sadr" <pf******@hotmail.comwrote in message
news:11**********************@a75g2000cwd.googlegr oups.com...
uh a half dozen MS press books???
uh a half dozen MS press books???
uh a half dozen MS press books???
get a spid; get another SPID.

DO THEY MATCH?

because if they do then I'll accept a written apology from Microsoft
and new editions of their books that are CORRECTED.
On Feb 16, 1:48 pm, "Brian Gideon" <briangid...@yahoo.comwrote:
>On Feb 16, 3:00 pm, pfc_s...@hotmail.com wrote:
I didn't think that you could even leave a connection open.
it's one of my biggest complaints about ADO.net; I used to use @@SPID
similiar to sessionID in ASP in order to build some simple apps...
but now there is nothing like that in .NET from what I understand
I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?
like I'm being serious and honest here.
Thanks

Hi,

What made you think you couldn't leave a connection open?

Brian


Feb 16 '07 #11

P: n/a
uh sorry about changing logins; most people think that I do it to be
dastardly; when in fact I only do it to get around this 'your ip has
posted too many ~~ crap on google groups'

I really don't try to be an asshole; I am just continously
flabberghasted by the poor architecture choices by the designers for
ADO.net.

I do not appreciate or grasp _ANY_ of these changes.
so I only use datareaders; because datasets seem overly complex to
me.. and I never cared for anything in vb6 except forward only, read-
only

(and of course, performance wins every decision in my book)

I've been writing SQL Server and Vb for a decade.
I started with Basic in 1982 on my commodore 64; and I'll never give
it up.

It just blows my mind; a bunch of drunk monkeys sitting around and
putting architecture solutions into a hat and randomly pulling out
solutions would end up a VASTLY SUPEROR architecture to this DOTNET
crap.

Did they purposefully handicap ADO.net???
I am DEAD SERIOUS.

http://www.startvbdotnet.com/ado/default.aspx

ADO was a connected data access, which means that when a connection to
the database is established the connection remains open until the
application is closed. Leaving the connection open for the lifetime of
the application raises concerns about database security and
network traffic. Also, as databases
are becoming increasingly important and as they are serving more
people, a connected data access model makes us think about its
productivity. For example, an application with connected data access
may do well when connected to two clients, the same may do poorly when
connected to 10 and might be unusable when connected to 100 or more.
Also, open database connections use system resources to a maximum
extent making the system performance less effective.

Why ADO.NET?

To cope up with some of the problems mentioned above, ADO .NET came
into existence. ADO .NET addresses the above mentioned problems by
maintaining a disconnected database access model which means, when an
application interacts with the database, the connection is opened to
serve the request of the application and is closed as soon as the
request is completed.


On Feb 16, 1:48 pm, "Brian Gideon" <briangid...@yahoo.comwrote:
On Feb 16, 3:00 pm, pfc_s...@hotmail.com wrote:
I didn't think that you could even leave a connection open.
it's one of my biggest complaints about ADO.net; I used to use @@SPID
similiar to sessionID in ASP in order to build some simple apps...
but now there is nothing like that in .NET from what I understand
I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?
like I'm being serious and honest here.
Thanks

Hi,

What made you think you couldn't leave a connection open?

Brian

Feb 16 '07 #12

P: n/a
"Cor Ligthert [MVP]" <no************@planet.nlschrieb:
AS you ask for Best Practice than you don't definitly not need a test to
see if your connection is open.

You control your program, so you know if it is open or not and can close
it therefore at the right time without any error.
Not really. Imagine an exception gets thrown when opening the connection.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Feb 16 '07 #13

P: n/a
"bigHairy" <mt*********@gmail.comschrieb:
A number of examples I have followed have the following in their
finally statement

Try
.....
Catch
.....
Finally

If (Not IsNothing(dbConn)) Then
dbConn.Close()
End If

End Try

Will my data connection always close using this method or should I
just use dbConn.close?
It will always close because the code inside the 'Finally' branch will be
executed even if the the procedure is left using 'Return' or 'Exit *' inside
'Try' and 'Catch'.

However, I'd prefer this way to write down the code in the 'Finally' block:

\\\
If dbConn IsNot Nothing Then
dbConn.Close()
End If
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Feb 16 '07 #14

P: n/a
I didn't ask for an essay on whether it is good or bad. Leaving a
connection OPEN is a requirment for any data access layer that I use;
and I'm not willing to budge on it. I'm not short-sighted; I am
_PRACTICAL_.

For an office with a half dozen users; using a single connection for
each user is hard to beat.

Yes; there are some places I don't want to reuse the same connection
for a single user all day.

But ADO allowed the flexibility to use either strategy.
UNNECESSARY CHANGE IS NOT SEXY.
I DO NOT ACCEPT THE PREMISE THAT IT IS ACCEPTABLE FOR MICROSOFT TO
DICTATE HOW WE WRITE CODE.

WHEN SOMETHING _WORKS_ AND IT HAS WORKED FOR A DECADE, WHY CHANGE IT?

IF SOMETHING IS NOT BROKEN THEN DO NOT CHANGE IT.

from what I understand; it is impossible to get the same SPID from a
single connection in ADO.net that I leave open.

IS THAT CORRECT?

because if it is; then it is just another day in the HOLY WAR AGAINST
DOTNET _CRAP_.
because if it is; then it is just another day in the HOLY WAR AGAINST
DOTNET _CRAP_.
because if it is; then it is just another day in the HOLY WAR AGAINST
DOTNET _CRAP_.
because if it is; then it is just another day in the HOLY WAR AGAINST
DOTNET _CRAP_.
because if it is; then it is just another day in the HOLY WAR AGAINST
DOTNET _CRAP_.
if MS stops introducing 'unnecessary change' for NO PRACTICAL REASON
(and fixes this transgression) then maybe.. just _MAYBE_ I'll lay down
my arms.

-Aaron


On Feb 16, 2:13 pm, "Chris Mullins [MVP]" <cmull...@yahoo.comwrote:
I think you misunderstood what the MS-Press books were saying.

The opening and closing of ADO.NET connections, along with the implications
this has on the connection pool, can catch people by surprise.

The general rule for your code is open / execute / close - this is how best
you're able to work with the connection pool. There's nothing stopping you
from doing other things though - like holding connections open, or any of a
dozen other (bad) things.

Be aware that, under the hood, open / close don't actually open or close
database connections. IT's more "Check out from pool", "Check back into
pool". It's up the pool as to when the connections are actually opened and
closed.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVPhttp://www.coversant.com/blogs/cmullins

"PFC Sadr" <pfc_s...@hotmail.comwrote in message

news:11**********************@a75g2000cwd.googlegr oups.com...
uh a half dozen MS press books???
uh a half dozen MS press books???
uh a half dozen MS press books???
get a spid; get another SPID.
DO THEY MATCH?
because if they do then I'll accept a written apology from Microsoft
and new editions of their books that are CORRECTED.
On Feb 16, 1:48 pm, "Brian Gideon" <briangid...@yahoo.comwrote:
On Feb 16, 3:00 pm, pfc_s...@hotmail.com wrote:
I didn't think that you could even leave a connection open.
it's one of my biggest complaints about ADO.net; I used to use @@SPID
similiar to sessionID in ASP in order to build some simple apps...
but now there is nothing like that in .NET from what I understand
I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?
like I'm being serious and honest here.
Thanks
Hi,
What made you think you couldn't leave a connection open?
Brian

Feb 16 '07 #15

P: n/a
re:
Be aware that, under the hood, open / close don't actually open or close
database connections. IT's more "Check out from pool", "Check back into
pool". It's up the pool as to when the connections are actually opened and
closed.


it's OBVIOUS that Microsoft and you DOTNET _FAGS_ are on the losing
side of this argument.

UNNECESSARY CHANGE IS NOT SEXY
UNNECESSARY CHANGE IS NOT EFFICIENT
UNNECESSARY CHANGE IS NOT ACCEPTABLE

On Feb 16, 2:13 pm, "Chris Mullins [MVP]" <cmull...@yahoo.comwrote:
I think you misunderstood what the MS-Press books were saying.

The opening and closing of ADO.NET connections, along with the implications
this has on the connection pool, can catch people by surprise.

The general rule for your code is open / execute / close - this is how best
you're able to work with the connection pool. There's nothing stopping you
from doing other things though - like holding connections open, or any of a
dozen other (bad) things.

Be aware that, under the hood, open / close don't actually open or close
database connections. IT's more "Check out from pool", "Check back into
pool". It's up the pool as to when the connections are actually opened and
closed.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVPhttp://www.coversant.com/blogs/cmullins

"PFC Sadr" <pfc_s...@hotmail.comwrote in message

news:11**********************@a75g2000cwd.googlegr oups.com...
uh a half dozen MS press books???
uh a half dozen MS press books???
uh a half dozen MS press books???
get a spid; get another SPID.
DO THEY MATCH?
because if they do then I'll accept a written apology from Microsoft
and new editions of their books that are CORRECTED.
On Feb 16, 1:48 pm, "Brian Gideon" <briangid...@yahoo.comwrote:
On Feb 16, 3:00 pm, pfc_s...@hotmail.com wrote:
I didn't think that you could even leave a connection open.
it's one of my biggest complaints about ADO.net; I used to use @@SPID
similiar to sessionID in ASP in order to build some simple apps...
but now there is nothing like that in .NET from what I understand
I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?
like I'm being serious and honest here.
Thanks
Hi,
What made you think you couldn't leave a connection open?
Brian

Feb 16 '07 #16

P: n/a
I'd prefer to leave the connection open so that I can _POSSIBLY_
troubleshoot things on the database side.

ESPECIALLY---- ESPECILALLY-- DURING DEVELOPMENT
ESPECIALLY---- ESPECILALLY-- DURING DEVELOPMENT
ESPECIALLY---- ESPECILALLY-- DURING DEVELOPMENT
ESPECIALLY---- ESPECILALLY-- DURING DEVELOPMENT
On Feb 16, 2:33 pm, "Herfried K. Wagner [MVP]" <hirf-spam-me-
h...@gmx.atwrote:
"bigHairy" <mthomas1...@gmail.comschrieb:
A number of examples I have followed have the following in their
finally statement
Try
.....
Catch
.....
Finally
If (Not IsNothing(dbConn)) Then
dbConn.Close()
End If
End Try
Will my data connection always close using this method or should I
just use dbConn.close?

It will always close because the code inside the 'Finally' branch will be
executed even if the the procedure is left using 'Return' or 'Exit *' inside
'Try' and 'Catch'.

However, I'd prefer this way to write down the code in the 'Finally' block:

\\\
If dbConn IsNot Nothing Then
dbConn.Close()
End If
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Feb 16 '07 #17

P: n/a
and for the record, I didn't 'mis-understand' the MS Press book.

DO _NOT_ TRY TO DISCREDIT ME.

I HAVE SERIOUS, MILITANT GRIEVANCES.
UNLESS YOU CAN SHOW ME HOW TO KEEP A SINGLE SIMPLE CONNECTION OPEN I
AM STILL AT _WAR_ WITH MS AND ALL MVP

THANKS AND SORRY

-Aaron


On Feb 16, 2:13 pm, "Chris Mullins [MVP]" <cmull...@yahoo.comwrote:
I think you misunderstood what the MS-Press books were saying.

The opening and closing of ADO.NET connections, along with the implications
this has on the connection pool, can catch people by surprise.

The general rule for your code is open / execute / close - this is how best
you're able to work with the connection pool. There's nothing stopping you
from doing other things though - like holding connections open, or any of a
dozen other (bad) things.

Be aware that, under the hood, open / close don't actually open or close
database connections. IT's more "Check out from pool", "Check back into
pool". It's up the pool as to when the connections are actually opened and
closed.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVPhttp://www.coversant.com/blogs/cmullins

"PFC Sadr" <pfc_s...@hotmail.comwrote in message

news:11**********************@a75g2000cwd.googlegr oups.com...
uh a half dozen MS press books???
uh a half dozen MS press books???
uh a half dozen MS press books???
get a spid; get another SPID.
DO THEY MATCH?
because if they do then I'll accept a written apology from Microsoft
and new editions of their books that are CORRECTED.
On Feb 16, 1:48 pm, "Brian Gideon" <briangid...@yahoo.comwrote:
On Feb 16, 3:00 pm, pfc_s...@hotmail.com wrote:
I didn't think that you could even leave a connection open.
it's one of my biggest complaints about ADO.net; I used to use @@SPID
similiar to sessionID in ASP in order to build some simple apps...
but now there is nothing like that in .NET from what I understand
I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?
like I'm being serious and honest here.
Thanks
Hi,
What made you think you couldn't leave a connection open?
Brian

Feb 16 '07 #18

P: n/a
>
Not really. Imagine an exception gets thrown when opening the connection.

--
Absolutely not Herfried that is in your control, I did not say you should
not use Try and Catch. I mean there should not be needed a question as "If
connection is open"

Cor
Feb 17 '07 #19

P: n/a
PFC,

By using a dataadapter you don't even have to open and close a connection as
it is about one action.
(dataset, datatable, datarow). It does it completely self. If it was closed
it opens and closed it and leaves it in the state it was as it is closed.

If you have more tabels datasets to do in a row, than it can be more
efficient to open that only at the begin and close it at the end, something
as

Try
open myconnection
try
do my stuff
do my stuff
do my stuff
catch the problems in the stuff
handle the problems in my stuff
end try
Catch the problems in my connection
handle the problems in my connection
End Catch

Cor

<pf******@hotmail.comschreef in bericht
news:11**********************@q2g2000cwa.googlegro ups.com...
>I didn't think that you could even leave a connection open.

it's one of my biggest complaints about ADO.net; I used to use @@SPID
similiar to sessionID in ASP in order to build some simple apps...

but now there is nothing like that in .NET from what I understand

I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?
like I'm being serious and honest here.

Thanks

On Feb 16, 12:04 pm, "Stephany Young" <noone@localhostwrote:
>The issue here has nothing to do with whether or not the database
connection
is open. It is to do with whether or not the database connection object
has
been instantiated.

You will probabaly note that the 'examples' have the dbConn variable
declared before the Try. This means that the dbConn variable is 'scoped'
so
that it is available to the Finally block.

With both the SqlConnection and OleDbConnection classes, calling Close on
an
object of those types that is not open will NOT cause an exception.
However,
if you call Close on an object of those types that has NOT been
instantiated
(Is Nothing) then an exception WILL be thrown.

In the Try block, if an exception is thrown before dbConn is instantiated
(let alone opened), the logic will 'jump' directly to the Catch block and
then fall through to the Finally block. At this point dbConn would be
Nothing and a call to dbConn.Close would fail. The conditional execution
of
dbConn.Close handles this situation.

Because the code Finally block is executed regardless of whether an
exception was thrown or not, having the conditional execution of
dbConn.Close means that you do not need to worrying about closing the
connection in either the Try or Catch blocks.

"bigHairy" <mthomas1...@gmail.comwrote in message

news:11**********************@m58g2000cwm.googleg roups.com...
Hello.
I have been teaching myself .NET over the last few months and have had
some success. I would like to ask a question though...
A number of examples I have followed have the following in their
finally statement
Try
.....
Catch
.....
Finally
If (Not IsNothing(dbConn)) Then
dbConn.Close()
End If
End Try
Will my data connection always close using this method or should I
just use dbConn.close?
I have a program that seems to be holding onto its connection - am I
missing something?


Feb 17 '07 #20

P: n/a
"Cor Ligthert [MVP]" <no************@planet.nlschrieb:
>Not really. Imagine an exception gets thrown when opening the
connection.
Absolutely not Herfried that is in your control, I did not say you should
not use Try and Catch. I mean there should not be needed a question as "If
connection is open"
Why not? Pseudo code:

\\\
Dim c As New Connection()
Try
c.Open()
c.DoSomething()
Catch
...
Finally
c.Close()
End Try
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Feb 17 '07 #21

P: n/a
Herfried,

In your sample you don't know if it is an opening error or a processing
error.

It depend of course of the situation, I think that in a common situation (I
don't remember me that I did the first one in a real situation) that I am to
lazy for the first one, however asked was Best Practice.

Your sample is often used to show how finally can work. In my opinion that
is not because it is the best way how to do an open and close but there are
not so many more simple samples.

:-)

Cor

"Herfried K. Wagner [MVP]" <hi***************@gmx.atschreef in bericht
news:%2****************@TK2MSFTNGP02.phx.gbl...
"Cor Ligthert [MVP]" <no************@planet.nlschrieb:
>>Not really. Imagine an exception gets thrown when opening the
connection.
Absolutely not Herfried that is in your control, I did not say you should
not use Try and Catch. I mean there should not be needed a question as
"If connection is open"

Why not? Pseudo code:

\\\
Dim c As New Connection()
Try
c.Open()
c.DoSomething()
Catch
...
Finally
c.Close()
End Try
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Feb 17 '07 #22

P: n/a
pf******@hotmail.com wrote in news:1171659636.108644.239340
@q2g2000cwa.googlegroups.com:
I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?
It depends on the reader you use. If you use a data adapter, it'll close
for you.

However, datareaders use a firehose mode to read from the database, thus
you need to manually close it when you're done with the reader/connection.
Feb 17 '07 #23

P: n/a
That is not correct.

When a DataAdapter 'starts' it's operation it determines thae current state
of the Connection. If the Connection was already open then it leaves it open
when it finishes. If it needs to open the Connection then it closes the
Connection when it finishes.

In other words, it leaves the Connection in the state that it found it.
"Spam Catcher" <sp**********@rogers.comwrote in message
news:Xn*********************************@127.0.0.1 ...
pf******@hotmail.com wrote in news:1171659636.108644.239340
@q2g2000cwa.googlegroups.com:
>I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?

It depends on the reader you use. If you use a data adapter, it'll close
for you.

However, datareaders use a firehose mode to read from the database, thus
you need to manually close it when you're done with the reader/connection.
Feb 17 '07 #24

P: n/a
Spam

that is not an acceptable answer.

Your ADO.net _CRAP_ is unusable

UNNECESSARY CHANGE IS NOT SEXY
UNNECESSARY CHANGE IS NOT WANTED
UNNECESSARY CHANGE IS NOT ACCEPTABLE


On Feb 17, 12:31 pm, Spam Catcher <spamhoney...@rogers.comwrote:
pfc_s...@hotmail.com wrote in news:1171659636.108644.239340
@q2g2000cwa.googlegroups.com:
I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?

It depends on the reader you use. If you use a data adapter, it'll close
for you.

However, datareaders use a firehose mode to read from the database, thus
you need to manually close it when you're done with the reader/connection.

Feb 19 '07 #25

P: n/a
Stephany

I don't care whether is 'says' it is open or not.
it does not maintain the same spid; you and Microsoft merely play word
games.

ADO.net is not usable, UNNECESSARY CHANGE IS NOT ACCEPTABLE


On Feb 17, 12:38 pm, "Stephany Young" <noone@localhostwrote:
That is not correct.

When a DataAdapter 'starts' it's operation it determines thae current state
of the Connection. If the Connection was already open then it leaves it open
when it finishes. If it needs to open the Connection then it closes the
Connection when it finishes.

In other words, it leaves the Connection in the state that it found it.

"Spam Catcher" <spamhoney...@rogers.comwrote in message

news:Xn*********************************@127.0.0.1 ...
pfc_s...@hotmail.com wrote in news:1171659636.108644.239340
@q2g2000cwa.googlegroups.com:
I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?
It depends on the reader you use. If you use a data adapter, it'll close
for you.
However, datareaders use a firehose mode to read from the database, thus
you need to manually close it when you're done with the reader/connection.- Hide quoted text -

- Show quoted text -

Feb 19 '07 #26

P: n/a
Spam

ok.. ok.. how we're getting somewhere

if I just use datareaders (why in the hell would I want to use
datasets?)
then it will keep the same SPID even with 20 people hitting the
database?

I just think that the whole 'automagically close connections' is
misguided
and when MS Press sits there and says crap like 'uh you guys cant
remember to use the .MoveNext method so we've fixed it for you by
using the .Read' method

I just get a little bit defensive

I didn't ask for MIcrosoft to talk down to us-- just because we use
the WORLDS MOST POPULAR PROGRAMMING LANGUAGE
I mean; are you guys not pissed off by the tone of that authors voice?

it's just reflective of what M$ thinks of VB people

so... _FUCK_MS_


On Feb 17, 12:31 pm, Spam Catcher <spamhoney...@rogers.comwrote:
pfc_s...@hotmail.com wrote in news:1171659636.108644.239340
@q2g2000cwa.googlegroups.com:
I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?

It depends on the reader you use. If you use a data adapter, it'll close
for you.

However, datareaders use a firehose mode to read from the database, thus
you need to manually close it when you're done with the reader/connection.

Feb 19 '07 #27

P: n/a
I don't WANT to manually close it.
I want to leave it OPEN.
I don't see the point of opening it and re-opening it and all that
crap
and you can't utilize temp tables if your provider keeps on randomly
closing connections

uh; like seriously here

let's talk about programming apps for small business.
why would I constantly open and close and open and close connections??

On Feb 17, 12:31 pm, Spam Catcher <spamhoney...@rogers.comwrote:
pfc_s...@hotmail.com wrote in news:1171659636.108644.239340
@q2g2000cwa.googlegroups.com:
I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?

It depends on the reader you use. If you use a data adapter, it'll close
for you.

However, datareaders use a firehose mode to read from the database, thus
you need to manually close it when you're done with the reader/connection.

Feb 19 '07 #28

P: n/a
PFC,

I have the same, when I have to drive less than 150miles an hour, than I
hate that, why would I do that, just for security by instance like opening
and closing the connections to prevent that there are pooling of whatever
problems.

Cor
"PFC Sadr" <pf******@hotmail.comschreef in bericht
news:11**********************@l53g2000cwa.googlegr oups.com...
>I don't WANT to manually close it.
I want to leave it OPEN.
I don't see the point of opening it and re-opening it and all that
crap
and you can't utilize temp tables if your provider keeps on randomly
closing connections

uh; like seriously here

let's talk about programming apps for small business.
why would I constantly open and close and open and close connections??

On Feb 17, 12:31 pm, Spam Catcher <spamhoney...@rogers.comwrote:
>pfc_s...@hotmail.com wrote in news:1171659636.108644.239340
@q2g2000cwa.googlegroups.com:
I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?

It depends on the reader you use. If you use a data adapter, it'll close
for you.

However, datareaders use a firehose mode to read from the database, thus
you need to manually close it when you're done with the
reader/connection.


Feb 20 '07 #29

P: n/a
Cor

I don't understand what you're trying to say to me here.

Are you saying that you are GLAD that they automagically close
connections?

IT SHOULD BE OPTIONAL NOT MANDATORY

JUST LIKE IT WAS IN ADO; USING CONNECTION SHARING


On Feb 19, 8:32 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
PFC,

I have the same, when I have to drive less than 150miles an hour, than I
hate that, why would I do that, just for security by instance like opening
and closing the connections to prevent that there are pooling of whatever
problems.

Cor

"PFC Sadr" <pfc_s...@hotmail.comschreef in berichtnews:11**********************@l53g2000cwa.g ooglegroups.com...
I don't WANT to manually close it.
I want to leave it OPEN.
I don't see the point of opening it and re-opening it and all that
crap
and you can't utilize temp tables if your provider keeps on randomly
closing connections
uh; like seriously here
let's talk about programming apps for small business.
why would I constantly open and close and open and close connections??
On Feb 17, 12:31 pm, Spam Catcher <spamhoney...@rogers.comwrote:
pfc_s...@hotmail.com wrote in news:1171659636.108644.239340
@q2g2000cwa.googlegroups.com:
I just don't understand; why do you even need to close a connection if
you can't leave a connection OPEN?
It depends on the reader you use. If you use a data adapter, it'll close
for you.
However, datareaders use a firehose mode to read from the database, thus
you need to manually close it when you're done with the
reader/connection.- Hide quoted text -

- Show quoted text -

Feb 20 '07 #30

P: n/a
On Feb 20, 12:27 am, "aaron.ke...@gmail.com" <aaron.ke...@gmail.com>
wrote:
Cor

I don't understand what you're trying to say to me here.

Are you saying that you are GLAD that they automagically close
connections?

IT SHOULD BE OPTIONAL NOT MANDATORY

JUST LIKE IT WAS IN ADO; USING CONNECTION SHARING
Hi,

Like Spam said, closing a connection in ADO.NET is optional. You can
keep that IDbConnection object open as long as you'd like.

Brian

Feb 20 '07 #31

P: n/a
PFC Sadr wrote:
I don't WANT to manually close it.
I want to leave it OPEN.
I don't see the point of opening it and re-opening it and all that
crap
and you can't utilize temp tables if your provider keeps on randomly
closing connections

uh; like seriously here

let's talk about programming apps for small business.
why would I constantly open and close and open and close connections??
This is especially important for small businesses. If a company has 10
PCs that need to connect to an SQL server throughout the day, but not
every PC needs to look at the data all day, they might be able to get
away with 5 licenses. If you keep those connections open the whole time
the application is open, you couldn't do that. We even have a company
that needs 8 people to connect to it constantly through the day. We
close connections and only open them when needed. They have 5 licenses
and have never had a problem. It's very cost effective.

It's also important for large companies. Having 100 connections open all
day is not very efficient when you can have 10 - 25 connections opening
and closing. Less load on the server...

It's just smarter and more efficient.
Feb 20 '07 #32

P: n/a
There's another benefit to designing systems to open and close connections,
especially connections that sit idle most of the time. If your clients
assume that the connection is always open once it is opened, any burp that
causes the server to drop the connection will crash the client. If the
client doesn't make this assumption, a dropped connection is no big deal,
which also means the server can drop idle connections to free resources and
the client will simply reconnect when it needs to.

Mike Ober.

"CodeMonkey" <sp******@suck.comwrote in message
news:um*************@TK2MSFTNGP04.phx.gbl...
PFC Sadr wrote:
>I don't WANT to manually close it.
I want to leave it OPEN.
I don't see the point of opening it and re-opening it and all that
crap
and you can't utilize temp tables if your provider keeps on randomly
closing connections

uh; like seriously here

let's talk about programming apps for small business.
why would I constantly open and close and open and close connections??

This is especially important for small businesses. If a company has 10 PCs
that need to connect to an SQL server throughout the day, but not every PC
needs to look at the data all day, they might be able to get away with 5
licenses. If you keep those connections open the whole time the
application is open, you couldn't do that. We even have a company that
needs 8 people to connect to it constantly through the day. We close
connections and only open them when needed. They have 5 licenses and have
never had a problem. It's very cost effective.

It's also important for large companies. Having 100 connections open all
day is not very efficient when you can have 10 - 25 connections opening
and closing. Less load on the server...

It's just smarter and more efficient.

Feb 20 '07 #33

P: n/a
I DISAGREE.

Like someone else said; it automagically closes the connection for me.

Is it possible to have a single user tied to the same SPID throughout
the life of their workday?

if the answer is no then you guys need to STFU and stop playing word
games.
>From what I've seen-- I can't keep a connection open; and I've gotten
at least half of these people to agree with me.

You guys can sit there and say 'yeah but MS says the connection is
still open' but it IS NOT OPEN.

RIGHT?

On Feb 20, 5:06 am, "Brian Gideon" <briangid...@yahoo.comwrote:
On Feb 20, 12:27 am, "aaron.ke...@gmail.com" <aaron.ke...@gmail.com>
wrote:
Cor
I don't understand what you're trying to say to me here.
Are you saying that you are GLAD that they automagically close
connections?
IT SHOULD BE OPTIONAL NOT MANDATORY
JUST LIKE IT WAS IN ADO; USING CONNECTION SHARING

Hi,

Like Spam said, closing a connection in ADO.NET is optional. You can
keep that IDbConnection object open as long as you'd like.

Brian

Feb 20 '07 #34

P: n/a
CodeMonkey

I militantly disagree. They should have left it the same as it was in
ADO. Unnecessary change is not acceptable.

I've got solutions usign temp tables all over the puget sound region.

CAN THEY BE REWRITTEN TO USE ADO.NET ?

NOT POSSIBLE

I'm sorry that you've got ONE CUSTOMER that is friggin stupid enough
to buy CALs. SQL Server Express edition doesn't require CALs and
it's a great option for Small Businesses.

EXCEPT FOR THE FACT THAT IT AUTOMAGICALLY CLOSES CONNECTIONS FOR ME.

TAKE THIS MODEL AND SHOVE IT
In ADO we could either leave a connection open; or we could use
connection pooling... or just a connection string without an explicit
connection.

In ADO.net they decided that it would be best for everyone to change
_EVERYTHING_ without any foresight.
and now they sit here in MS Press and say crap like 'you kids are too
stupid to use .MoveNext so we changed it to just use the .Read method'

I mean WHAT THE FUCK IS UP WITH THIS COMPANY

they'll probably do the same as DAO-- kill ADO for a bunch of years
and then bring it back just because too many people are bitching up a
storm.

I just think that it's hilarious...

I mean.. they brought back DAO but they're still killing ADO... THIS
YEAR.
what's going to happen next year they mandate that we all use RDO?

FUCK MS THEY CAN BURN IN HELL.
I'm moving everything to Dreamweaver, PHP and mySql.

Because Microsoft is a bunch of drunk fratboys that don't have ANY
FUCKING RESPECT for existing codebases.

Sorry kid... I don't buy it.
MS says that we can keep a connection open; but it automagically
closes it for us.

I don't accept anything other than you guys saying 'yes Aaron, you are
right, fuck MS let us work together to get some rationality out of
Redmond'

-Aaron


On Feb 20, 5:51 am, CodeMonkey <spamm...@suck.comwrote:
PFC Sadr wrote:
I don't WANT to manually close it.
I want to leave it OPEN.
I don't see the point of opening it and re-opening it and all that
crap
and you can't utilize temp tables if your provider keeps on randomly
closing connections
uh; like seriously here
let's talk about programming apps for small business.
why would I constantly open and close and open and close connections??

This is especially important for small businesses. If a company has 10
PCs that need to connect to an SQL server throughout the day, but not
every PC needs to look at the data all day, they might be able to get
away with 5 licenses. If you keep those connections open the whole time
the application is open, you couldn't do that. We even have a company
that needs 8 people to connect to it constantly through the day. We
close connections and only open them when needed. They have 5 licenses
and have never had a problem. It's very cost effective.

It's also important for large companies. Having 100 connections open all
day is not very efficient when you can have 10 - 25 connections opening
and closing. Less load on the server...

It's just smarter and more efficient.- Hide quoted text -

- Show quoted text -

Feb 20 '07 #35

P: n/a
it is NOT smarter and more efficient.

IT IS CALLED UNNECESSARY CHANGE.

I DEMAND THE ABILITY TO HAVE ONE CONNECTION FOR A PARTICULAR USER. IT
MAKES DBA WORK _MANAGEABLE_.

USING CONNECTIONS THAT CLOSE EVEN THOUGH IT SAYS THAT THE CONNECTION
IS STILL OPEN?

WHAT PLANET IS THIS COMPANY FROM?

WHERE DOES MS GET ALL OF IT'S CRYSTAL METH FROM? BECAUSE THEY ARE SO
FUCKING DELUSIONAL THEY ARE OBVIOUSLY SNORTING METH.

FUCK MS; I CALL FOR THE US AIRFORCE TO BOMB MICROSOFT INTO SUBMISSION.

And for Steve Ballmer to be executed on Pay-Per-View. Dipshit
authorized C# and he deserves a baseball bat upside his head.

BRING IN RALPH NADER. HE IS THE ONLY PERSON THAT CAN SAVE MICROSOFT
AT THIS POINT.

On Feb 20, 5:51 am, CodeMonkey <spamm...@suck.comwrote:
PFC Sadr wrote:
I don't WANT to manually close it.
I want to leave it OPEN.
I don't see the point of opening it and re-opening it and all that
crap
and you can't utilize temp tables if your provider keeps on randomly
closing connections
uh; like seriously here
let's talk about programming apps for small business.
why would I constantly open and close and open and close connections??

This is especially important for small businesses. If a company has 10
PCs that need to connect to an SQL server throughout the day, but not
every PC needs to look at the data all day, they might be able to get
away with 5 licenses. If you keep those connections open the whole time
the application is open, you couldn't do that. We even have a company
that needs 8 people to connect to it constantly through the day. We
close connections and only open them when needed. They have 5 licenses
and have never had a problem. It's very cost effective.

It's also important for large companies. Having 100 connections open all
day is not very efficient when you can have 10 - 25 connections opening
and closing. Less load on the server...

It's just smarter and more efficient.- Hide quoted text -

- Show quoted text -

Feb 20 '07 #36

P: n/a
Michael;

I don't agree.
You can sit there and try to convince me to close connections BY
MYSELF.

but a connection that automagically closes itself for me?

WORTHLESS AT BEST.

MS NEEDS TO STOP HIRING MINIMUM WAGE GOOKS THAT CANNOT SPEAK ENGLISH

On Feb 20, 5:59 am, "Michael D. Ober" <obermd.@.alum.mit.edu.nospam>
wrote:
There's another benefit to designing systems to open and close connections,
especially connections that sit idle most of the time. If your clients
assume that the connection is always open once it is opened, any burp that
causes the server to drop the connection will crash the client. If the
client doesn't make this assumption, a dropped connection is no big deal,
which also means the server can drop idle connections to free resources and
the client will simply reconnect when it needs to.

Mike Ober.

"CodeMonkey" <spamm...@suck.comwrote in message

news:um*************@TK2MSFTNGP04.phx.gbl...
PFC Sadr wrote:
I don't WANT to manually close it.
I want to leave it OPEN.
I don't see the point of opening it and re-opening it and all that
crap
and you can't utilize temp tables if your provider keeps on randomly
closing connections
uh; like seriously here
let's talk about programming apps for small business.
why would I constantly open and close and open and close connections??
This is especially important for small businesses. If a company has 10 PCs
that need to connect to an SQL server throughout the day, but not every PC
needs to look at the data all day, they might be able to get away with 5
licenses. If you keep those connections open the whole time the
application is open, you couldn't do that. We even have a company that
needs 8 people to connect to it constantly through the day. We close
connections and only open them when needed. They have 5 licenses and have
never had a problem. It's very cost effective.
It's also important for large companies. Having 100 connections open all
day is not very efficient when you can have 10 - 25 connections opening
and closing. Less load on the server...
It's just smarter and more efficient.- Hide quoted text -

- Show quoted text -

Feb 20 '07 #37

P: n/a
On Feb 20, 10:27 am, "aaron.ke...@gmail.com" <aaron.ke...@gmail.com>
wrote:
I DISAGREE.

Like someone else said; it automagically closes the connection for me.
That's only if you choose to use the IDbDataAdapter interface and work
with DataSets. You can do everything manually as you did in classic
ADO.
>
Is it possible to have a single user tied to the same SPID throughout
the life of their workday?
Baring the obvious network outages, pc reboots, application shutdowns,
etc....yes. Just don't call Close or Dispose on the IDbConnection
object and use IDataReader objects to populate your own data
structures in memory.
if the answer is no then you guys need to STFU and stop playing word
games.

From what I've seen-- I can't keep a connection open; and I've gotten

at least half of these people to agree with me.

You guys can sit there and say 'yeah but MS says the connection is
still open' but it IS NOT OPEN.

RIGHT?
No, that's not right. I do it all the time. That is, I open a
connection, run a few commands, and then close the connection
manually. In your particular scenario you would want to omit that
last step and just leave the connection open for the life of the
application.

Feb 20 '07 #38

P: n/a
best news i heard all month, i'll warn those newsgroups to get ready for
vulgarity
I'm moving everything to Dreamweaver, PHP and mySql.

Feb 20 '07 #39

P: n/a
aa*********@gmail.com wrote:
CodeMonkey

I militantly disagree. They should have left it the same as it was in
ADO. Unnecessary change is not acceptable.
Unnecessary? Just because you can make sloppy code doesn't make it
right. Leaving connections open all day long is a very bad way to do
things on many different levels. They teach this in DBA 101. Since you
are one, I assumed that you knew this...
I don't accept anything other than you guys saying 'yes Aaron, you are
right, fuck MS let us work together to get some rationality out of
Redmond'

-Aaron
You are going to have a hard time convincing people. One, you have been
wrong on most, if not all, of the arguments that you bring up.

Look, if you really want to make an argument, you have to at least learn
about what you are arguing against. Nothing you have ever posted has
lead me to believe that you have even tried to learn about VB.Net. A lot
of the things that you yell about in here are not true. You need to try
to verify things before you try to argue about them. Whenever someone
has proved you wrong, you just say you disagree and call Microsoft
names. How is that even trying to get your point across?

If you want anyone to even believe you, you need to at least try to
learn it first. Just telling people that you refuse to change just tells
people you are old and worthless in the industry.
Feb 20 '07 #40

P: n/a
CodeMonkey <sp******@suck.comwrote in news:A9ICh.65107$wc5.60114
@newssvr25.news.prodigy.net:
>I militantly disagree. They should have left it the same as it was in
ADO. Unnecessary change is not acceptable.

Unnecessary? Just because you can make sloppy code doesn't make it
right. Leaving connections open all day long is a very bad way to do
things on many different levels. They teach this in DBA 101. Since you
are one, I assumed that you knew this...
Don't feed the trolls please ;-)
Feb 20 '07 #41

P: n/a
now why in the hell would I use ADO in .NET?

it works well enough in VB

they tried to sell us on performance AND WE DID NOT NEED PERFORMANCE.

I just don't accept a programmign language that 'calls a connection
open but it's really closed'
I don't think that is a good way to do business.
And I dont think that your premise -- the closing connections
automagically is a good thing-- should be forced down our throats.

that is the bottom line.

ADO does everything DOTNET does and then some.
you don't need to worry about having 2 recordsets open on the same
connection.

AND THE ASSHOLES SUPPOSEDLY FIXED IT WITH 'MARS' BUT DOES THAT HELP?
DOES IT ALLOW US MULTIPLE DATA READERS ON A SINGLE CONNECTION?

I just don't agree with all of the hocus pocus.

I won't put up with a company that talks down to us and says 'just
because you kids couldn't remember to use .MoveNext; we took it away;
and now all you've got do to is .Read'

I mean seriously here.

WHEN DID MICROSOFT GET UNILATERAL DECISION MAKING POWER?
WHEN DID MICROSOFT GET UNILATERAL DECISION MAKING POWER?
WHEN DID MICROSOFT GET UNILATERAL DECISION MAKING POWER?
WHEN DID MICROSOFT GET UNILATERAL DECISION MAKING POWER?

I refuse to take marching orders from some dipshit project manager at
Microsoft

when they FIRED ME FOR SPEAKING THE MOTHER FUCKING TRUTH IS WHEN I
GREW A BACKBONE.

I WORKED AT MSN QUALITY OF SERVICE; I LOST 13 EMAILS -- 13 RANDOM
EMAIL BOUNCES IN A MATTER OF A MONTH AND _I_ GET FIRED FOR
COMPLAINING?

FUCK MS AND FUCK UNNECESSARY CHANGE

I'll just wait until the next release of Visual Fred.
I've been saying it for 5 years and i've yet to see somethign that I
need.

On Feb 20, 9:55 am, "Brian Gideon" <briangid...@yahoo.comwrote:
On Feb 20, 10:27 am, "aaron.ke...@gmail.com" <aaron.ke...@gmail.com>
wrote:
I DISAGREE.
Like someone else said; it automagically closes the connection for me.

That's only if you choose to use the IDbDataAdapter interface and work
with DataSets. You can do everything manually as you did in classic
ADO.
Is it possible to have a single user tied to the same SPID throughout
the life of their workday?

Baring the obvious network outages, pc reboots, application shutdowns,
etc....yes. Just don't call Close or Dispose on the IDbConnection
object and use IDataReader objects to populate your own data
structures in memory.
if the answer is no then you guys need to STFU and stop playing word
games.
From what I've seen-- I can't keep a connection open; and I've gotten
at least half of these people to agree with me.
You guys can sit there and say 'yeah but MS says the connection is
still open' but it IS NOT OPEN.
RIGHT?

No, that's not right. I do it all the time. That is, I open a
connection, run a few commands, and then close the connection
manually. In your particular scenario you would want to omit that
last step and just leave the connection open for the life of the
application.

Feb 21 '07 #42

P: n/a
First off you're trying to tell me that 'leaving connections open is
possible in .NET' now you're telling me that it is a bad thing and its
GOOD that ADO.net won't let me do this?

NO. IN ADO I COULD USE CONNECTION POOLING OR I COULD LEAVE A
CONNECTION OPEN.
IF I WANT TO LEAVE A CONNECTION OPEN; I"LL FUCKING LEAVE MY OWN
GODDAMN CONNECTION OPEN.

but sitting here and playing word games 'yeah you can leave your
connection open but its 'not really open''

I MEAN GAG ME WITH A FUCKING SPOON KIDS


On Feb 20, 11:41 am, CodeMonkey <spamm...@suck.comwrote:
aaron.ke...@gmail.com wrote:
CodeMonkey
I militantly disagree. They should have left it the same as it was in
ADO. Unnecessary change is not acceptable.

Unnecessary? Just because you can make sloppy code doesn't make it
right. Leaving connections open all day long is a very bad way to do
things on many different levels. They teach this in DBA 101. Since you
are one, I assumed that you knew this...
I don't accept anything other than you guys saying 'yes Aaron, you are
right, fuck MS let us work together to get some rationality out of
Redmond'
-Aaron

You are going to have a hard time convincing people. One, you have been
wrong on most, if not all, of the arguments that you bring up.

Look, if you really want to make an argument, you have to at least learn
about what you are arguing against. Nothing you have ever posted has
lead me to believe that you have even tried to learn about VB.Net. A lot
of the things that you yell about in here are not true. You need to try
to verify things before you try to argue about them. Whenever someone
has proved you wrong, you just say you disagree and call Microsoft
names. How is that even trying to get your point across?

If you want anyone to even believe you, you need to at least try to
learn it first. Just telling people that you refuse to change just tells
people you are old and worthless in the industry.

Feb 21 '07 #43

P: n/a
EAT SHIT I AM NOT A TROLL

THE TROLLS ARE THE DIPSHITS THAT KILLED THE WORLDS MOST POPULAR
LANGUAGE
VB IS DEAD
AND NO ONE CARES

IF THERE WAS A HELL
I WOULD SEND MICROSOFT THERE


On Feb 20, 12:31 pm, Spam Catcher <spamhoney...@rogers.comwrote:
CodeMonkey <spamm...@suck.comwrote in news:A9ICh.65107$wc5.60114
@newssvr25.news.prodigy.net:
I militantly disagree. They should have left it the same as it was in
ADO. Unnecessary change is not acceptable.
Unnecessary? Just because you can make sloppy code doesn't make it
right. Leaving connections open all day long is a very bad way to do
things on many different levels. They teach this in DBA 101. Since you
are one, I assumed that you knew this...

Don't feed the trolls please ;-)

Feb 21 '07 #44

P: n/a
I HAVE NOT BEEN WRONG ABOUT A SINGLE MOTHER FUCKING THING.

CAN I RUN VB DOTNET IN SQL SERVER JOBS?

CAN I LOOK AT THE RESULTS OF A TEMPORARY TABLE IN ADO.NET?

CAN I RUN VBS USING VB.NET?

IS IT EVEN CALLED VB.NET?

WHY DOES VS PRO 2005 _CRASH_ TWICE A DAY
WHY IS VB DEAD?

WHY DID MS INVENT CSHARP?

WHY IS MS PLAYING XBOX INSTEAD OF FIXING VB?

On Feb 20, 11:41 am, CodeMonkey <spamm...@suck.comwrote:
aaron.ke...@gmail.com wrote:
CodeMonkey
I militantly disagree. They should have left it the same as it was in
ADO. Unnecessary change is not acceptable.

Unnecessary? Just because you can make sloppy code doesn't make it
right. Leaving connections open all day long is a very bad way to do
things on many different levels. They teach this in DBA 101. Since you
are one, I assumed that you knew this...
I don't accept anything other than you guys saying 'yes Aaron, you are
right, fuck MS let us work together to get some rationality out of
Redmond'
-Aaron

You are going to have a hard time convincing people. One, you have been
wrong on most, if not all, of the arguments that you bring up.

Look, if you really want to make an argument, you have to at least learn
about what you are arguing against. Nothing you have ever posted has
lead me to believe that you have even tried to learn about VB.Net. A lot
of the things that you yell about in here are not true. You need to try
to verify things before you try to argue about them. Whenever someone
has proved you wrong, you just say you disagree and call Microsoft
names. How is that even trying to get your point across?

If you want anyone to even believe you, you need to at least try to
learn it first. Just telling people that you refuse to change just tells
people you are old and worthless in the industry.

Feb 21 '07 #45

P: n/a
I've written PLENTY of vb.net

I DONT LIKE IT.

Just because 'leaving a connection open is sloppy' does not mean that
MS should play word games and LIE TO US about whether or not a
connection is open.

I know VB.net like the back of my hand.

AM I AN OOP _FAG_?

OF MOTHER FUCKING COURSE NOT.

I use DATABASES not this class _CRAP_
Classes are for art fags and people that like to build apps that are
unnecessarily complex.

I can reuse code _BETTER_ using modules then you can with classes

TAKE THIS LANGUAGE AND SHOVE IT
On Feb 20, 11:41 am, CodeMonkey <spamm...@suck.comwrote:
aaron.ke...@gmail.com wrote:
CodeMonkey
I militantly disagree. They should have left it the same as it was in
ADO. Unnecessary change is not acceptable.

Unnecessary? Just because you can make sloppy code doesn't make it
right. Leaving connections open all day long is a very bad way to do
things on many different levels. They teach this in DBA 101. Since you
are one, I assumed that you knew this...
I don't accept anything other than you guys saying 'yes Aaron, you are
right, fuck MS let us work together to get some rationality out of
Redmond'
-Aaron

You are going to have a hard time convincing people. One, you have been
wrong on most, if not all, of the arguments that you bring up.

Look, if you really want to make an argument, you have to at least learn
about what you are arguing against. Nothing you have ever posted has
lead me to believe that you have even tried to learn about VB.Net. A lot
of the things that you yell about in here are not true. You need to try
to verify things before you try to argue about them. Whenever someone
has proved you wrong, you just say you disagree and call Microsoft
names. How is that even trying to get your point across?

If you want anyone to even believe you, you need to at least try to
learn it first. Just telling people that you refuse to change just tells
people you are old and worthless in the industry.

Feb 21 '07 #46

P: n/a

try to verify things?

open a connection

make a datareader

get a spid

close the datareader

open a new datareader

get a spid

IT IS A DIFFERENT SPID!!!!!
IT IS A DIFFERENT SPID!!!!!
IT IS A DIFFERENT SPID!!!!!
IT IS A DIFFERENT SPID!!!!!
IT IS A DIFFERENT SPID!!!!!

On Feb 20, 11:41 am, CodeMonkey <spamm...@suck.comwrote:
aaron.ke...@gmail.com wrote:
CodeMonkey
I militantly disagree. They should have left it the same as it was in
ADO. Unnecessary change is not acceptable.

Unnecessary? Just because you can make sloppy code doesn't make it
right. Leaving connections open all day long is a very bad way to do
things on many different levels. They teach this in DBA 101. Since you
are one, I assumed that you knew this...
I don't accept anything other than you guys saying 'yes Aaron, you are
right, fuck MS let us work together to get some rationality out of
Redmond'
-Aaron

You are going to have a hard time convincing people. One, you have been
wrong on most, if not all, of the arguments that you bring up.

Look, if you really want to make an argument, you have to at least learn
about what you are arguing against. Nothing you have ever posted has
lead me to believe that you have even tried to learn about VB.Net. A lot
of the things that you yell about in here are not true. You need to try
to verify things before you try to argue about them. Whenever someone
has proved you wrong, you just say you disagree and call Microsoft
names. How is that even trying to get your point across?

If you want anyone to even believe you, you need to at least try to
learn it first. Just telling people that you refuse to change just tells
people you are old and worthless in the industry.

Feb 21 '07 #47

P: n/a
and it will keep the same SPID?

not the last time I checked.

why would a company invent a new library and then play word games like
this?

keeping a connection open shoudl keep the same SPID should it not?

On Feb 20, 5:06 am, "Brian Gideon" <briangid...@yahoo.comwrote:
On Feb 20, 12:27 am, "aaron.ke...@gmail.com" <aaron.ke...@gmail.com>
wrote:
Cor
I don't understand what you're trying to say to me here.
Are you saying that you are GLAD that they automagically close
connections?
IT SHOULD BE OPTIONAL NOT MANDATORY
JUST LIKE IT WAS IN ADO; USING CONNECTION SHARING

Hi,

Like Spam said, closing a connection in ADO.NET is optional. You can
keep that IDbConnection object open as long as you'd like.

Brian

Feb 21 '07 #48

P: n/a
vulgarity?

MS kills the worlds most popular language and you're worried about
VULGARITY?

grow some balls kids


On Feb 20, 10:49 am, Jay Parzych <jimp...@cox.netwrote:
best news i heard all month, i'll warn those newsgroups to get ready for
vulgarity
I'm moving everything to Dreamweaver, PHP and mySql.- Hide quoted text -

- Show quoted text -

Feb 21 '07 #49

P: n/a
another benefit to designing systems to open and close connections?

ALL I AM ASKING FOR IS THE ABILITY TO OPEN AND CLOSE CONNECTIONS
MANUALLY.

FROM WHAT I UNDERSTAND, ADO.NET CLOSES THEM AUTOMAGICALLY AND THEN
REOPENS IT AUTOMAGICALLY BEHIND THE SCENES.

IT WAS TRUE THE LAST TIME I BOTHERED WITH ADO.NET SO SCREW MS
i'll just move to mySql / php / Dreamweaver.. I mean; if I'm going to
rewrite shit I might as well do it RIGHT instead of having to rewrite
everything every 12 months

I mean seriously a new flavor of Visual Fred is COMING SOON!

On Feb 20, 5:59 am, "Michael D. Ober" <obermd.@.alum.mit.edu.nospam>
wrote:
There's another benefit to designing systems to open and close connections,
especially connections that sit idle most of the time. If your clients
assume that the connection is always open once it is opened, any burp that
causes the server to drop the connection will crash the client. If the
client doesn't make this assumption, a dropped connection is no big deal,
which also means the server can drop idle connections to free resources and
the client will simply reconnect when it needs to.

Mike Ober.

"CodeMonkey" <spamm...@suck.comwrote in message

news:um*************@TK2MSFTNGP04.phx.gbl...
PFC Sadr wrote:
I don't WANT to manually close it.
I want to leave it OPEN.
I don't see the point of opening it and re-opening it and all that
crap
and you can't utilize temp tables if your provider keeps on randomly
closing connections
uh; like seriously here
let's talk about programming apps for small business.
why would I constantly open and close and open and close connections??
This is especially important for small businesses. If a company has 10 PCs
that need to connect to an SQL server throughout the day, but not every PC
needs to look at the data all day, they might be able to get away with 5
licenses. If you keep those connections open the whole time the
application is open, you couldn't do that. We even have a company that
needs 8 people to connect to it constantly through the day. We close
connections and only open them when needed. They have 5 licenses and have
never had a problem. It's very cost effective.
It's also important for large companies. Having 100 connections open all
day is not very efficient when you can have 10 - 25 connections opening
and closing. Less load on the server...
It's just smarter and more efficient.- Hide quoted text -

- Show quoted text -

Feb 21 '07 #50

51 Replies

This discussion thread is closed

Replies have been disabled for this discussion.