In our new .NET web applications, we try to limit the use of SqlConnection
to just one instance per page, even if there are multiple accesses to
various queries. The thinking behind is that this reduces the need to
getting and returning connections to the pool repeatedly if a page has
multiple calls to the DB, and each one manages its own connection. However,
this does requires more deliberate coding, like calling the
SqlConnection.C lose() method in the page's Dispose() method so it's
garanteed that the connection is closed when the page processing is done,
and also is not closed too early. What I'm thinking is whether this is
actually necessary because passing the Connection object into child controls
becomes a pretty big hassle when there are several user controls or custom
controls on the page. If the connection pool management is very efficient
then opening and closing connections repeatly in the code (which is really
getting and returning connections to the pool) wouldn't be a big deal, and
keeping the code simple would be more important. Could anyone give some
suggestions?
11  2896 
Bob, IIRC, so long as you open the connection with the same connection
string, it'll be pooled.
Alex Papadimoulis
" Bob" <bo*******@yaho o.com> wrote in message
news:Og******** *****@TK2MSFTNG P11.phx.gbl... In our new .NET web applications, we try to limit the use of SqlConnection
to just one instance per page, even if there are multiple accesses to
various queries. The thinking behind is that this reduces the need to
getting and returning connections to the pool repeatedly if a page has
multiple calls to the DB, and each one manages its own connection.
However, this does requires more deliberate coding, like calling the
SqlConnection.C lose() method in the page's Dispose() method so it's
garanteed that the connection is closed when the page processing is done,
and also is not closed too early. What I'm thinking is whether this is
actually necessary because passing the Connection object into child
controls becomes a pretty big hassle when there are several user controls or custom
controls on the page. If the connection pool management is very efficient
then opening and closing connections repeatly in the code (which is really
getting and returning connections to the pool) wouldn't be a big deal, and
keeping the code simple would be more important. Could anyone give some
suggestions?
Alex, thanks for your reply. I understand that the same connection string
reults in connections in the same pool. My question is whether getting and
returning connections to the pool have become so efficient in ADP.NET and
Sql Data Provider that there is no need to put in extra code in order to
reduce the number of getting and returning from say, 3 to 1.
Thanks
Bob
"Alex Papadimoulis" <al***@papadimo ulis.com> wrote in message
news:10******** *****@corp.supe rnews.com... Bob, IIRC, so long as you open the connection with the same connection
string, it'll be pooled.
Alex Papadimoulis
" Bob" <bo*******@yaho o.com> wrote in message
news:Og******** *****@TK2MSFTNG P11.phx.gbl... In our new .NET web applications, we try to limit the use of
SqlConnection to just one instance per page, even if there are multiple accesses to
various queries. The thinking behind is that this reduces the need to
getting and returning connections to the pool repeatedly if a page has
multiple calls to the DB, and each one manages its own connection.
However, this does requires more deliberate coding, like calling the
SqlConnection.C lose() method in the page's Dispose() method so it's
garanteed that the connection is closed when the page processing is
done, and also is not closed too early. What I'm thinking is whether this is
actually necessary because passing the Connection object into child
controls becomes a pretty big hassle when there are several user controls or
custom controls on the page. If the connection pool management is very
efficient then opening and closing connections repeatly in the code (which is
really getting and returning connections to the pool) wouldn't be a big deal,
and keeping the code simple would be more important. Could anyone give some
suggestions?
" Bob" <bo*******@yaho o.com> wrote in message
news:Og******** *****@TK2MSFTNG P11.phx.gbl... In our new .NET web applications, we try to limit the use of SqlConnection
to just one instance per page, even if there are multiple accesses to
various queries. The thinking behind is that this reduces the need to
getting and returning connections to the pool repeatedly if a page has
multiple calls to the DB
Someone can correct me if I'm wrong, but I believe getting and returning
connections from managed connection pool is very efficient -- otherwise it
wouldn't be much of a pooling/caching mechanism!
Brad Williams
Bob,
I don't believe there would be any noticible difference. You may be giving
up a few cycles to do that, but it really is a better practice. Write the
simpler, easier to manage code now. If you see a performance problem, then
optimize.
-- Alex Papadimoulis
" Bob" <bo*******@yaho o.com> wrote in message
news:em******** ******@tk2msftn gp13.phx.gbl... Alex, thanks for your reply. I understand that the same connection
string reults in connections in the same pool. My question is whether getting
and returning connections to the pool have become so efficient in ADP.NET and
Sql Data Provider that there is no need to put in extra code in order to
reduce the number of getting and returning from say, 3 to 1.
Thanks
Bob
"Alex Papadimoulis" <al***@papadimo ulis.com> wrote in message
news:10******** *****@corp.supe rnews.com... Bob, IIRC, so long as you open the connection with the same connection
string, it'll be pooled.
Alex Papadimoulis
" Bob" <bo*******@yaho o.com> wrote in message
news:Og******** *****@TK2MSFTNG P11.phx.gbl... In our new .NET web applications, we try to limit the use of SqlConnection to just one instance per page, even if there are multiple accesses to
various queries. The thinking behind is that this reduces the need to
getting and returning connections to the pool repeatedly if a page has
multiple calls to the DB, and each one manages its own connection.
However, this does requires more deliberate coding, like calling the
SqlConnection.C lose() method in the page's Dispose() method so it's
garanteed that the connection is closed when the page processing is done, and also is not closed too early. What I'm thinking is whether this
is actually necessary because passing the Connection object into child
controls becomes a pretty big hassle when there are several user controls or custom controls on the page. If the connection pool management is very efficient then opening and closing connections repeatly in the code (which is really getting and returning connections to the pool) wouldn't be a big deal, and keeping the code simple would be more important. Could anyone give
some suggestions?
Hmm, that's still not what I was asking. I understand how and where to
properly close a connection, why it should be done, where to set the pool
size and timeout etc. What I'm trying to get at is that, if I have a page
that needs to make a series of calls to the database, say, call SP 1 to get
some data to populate a drop down, then call SP 2 to get some other data to
populate a datagrid, in the same page a user control on the page calls SP 3
to get some status data to display on the sidebar. So I face a design
decision here. One way is to create one instance of the SqlConnection
object (could be handled by a middle tier but for discussion purpose let's
say I'm doing this directly from the aspx.cs class) and use it throughout
the page, and put the .Close() in the page Dispose() method so the
connection is closed at the end and only at the end of the page processing.
Alternatively, I can design it to let each call create its own instance of
the SqlConnection object and close it immediate after the call is done.
This way, I can wrap each call in its self contained function, and
particularly for the user control on the page, I don't have to get the
connection instance from the main page. This makes the code simpler and the
logic a lot easier to follow. However, the second option would use 3
different connections. Assuming the connections are already in the pool so
it doesn't have to create brand new ones, it would be getting and returning
connections to the pool 3 times, rather than 1 in the first option. So back
to my original questions, if getting and returning connections to the pool
has become so efficient that doing it 2 times more is no big deal at all
then I probably should go with option 2, otherwise I should still do option
1, which has more complicated coding particularly if a middle tier is
involved.
Thanks
"Bin Song, MCP" <an*******@disc ussions.microso ft.com> wrote in message
news:2C******** *************** ***********@mic rosoft.com... Hi, Bob
I understand your question now.
The returning of Connection to pool depend on when you close the
connection or the connection time out. The pool size and timeout can be
defined in the connection string. It is recommended that you always close the Connection when you are
finished using it in order for the connection to be returned to the pool.
This can be done using either the Close or Dispose methods of the Connection
object. Connections that are not explicitly closed might not be added or
returned to the pool. For example, a connection that has gone out of scope
but that has not been explicitly closed will only be returned to the
connection pool if the maximum pool size has been reached and the connection
is still valid.
Please see the following article:
http://msdn.microsoft.com/library/de...taProvider.asp
Bin Song, MCP
----- Bob wrote: -----
Alex, thanks for your reply. I understand that the same connection
string reults in connections in the same pool. My question is whether
getting and returning connections to the pool have become so efficient in ADP.NET
and Sql Data Provider that there is no need to put in extra code in order
to reduce the number of getting and returning from say, 3 to 1.
Thanks
Bob
"Alex Papadimoulis" <al***@papadimo ulis.com> wrote in message
news:10******** *****@corp.supe rnews.com... > Bob, IIRC, so long as you open the connection with the same
connection > string, it'll be pooled. >> Alex Papadimoulis > " Bob" <bo*******@yaho o.com> wrote in message
> news:Og******** *****@TK2MSFTNG P11.phx.gbl... >> In our new .NET web applications, we try to limit the use of SqlConnection >> to just one instance per page, even if there are multiple accesses
to >> various queries. The thinking behind is that this reduces the
need to >> getting and returning connections to the pool repeatedly if a page
has >> multiple calls to the DB, and each one manages its own connection.
> However, >> this does requires more deliberate coding, like calling the
>> SqlConnection.C lose() method in the page's Dispose() method so
it's >> garanteed that the connection is closed when the page processing
is done, >> and also is not closed too early. What I'm thinking is whether
this is >> actually necessary because passing the Connection object into
child > controls >> becomes a pretty big hassle when there are several user controls
or custom >> controls on the page. If the connection pool management is very efficient >> then opening and closing connections repeatly in the code (which
is really >> getting and returning connections to the pool) wouldn't be a big
deal, and >> keeping the code simple would be more important. Could anyone
give some >> suggestions?
>>>>>>
Bob,
You should use a single connection and just open and close as needed.
The connection in the pool is not really closed. It is just sitting there
waiting for you to ask for it again.
So you lose nothing to "close" a connection and the "open" it. It is already
open.
In my Business Objects I open a datareader to populate the BO and then close
it and re-open a 2nd dr to populate any contained BOs or collections. The
dr.close also "closes" the connection but then I re-open it and poulate the
next object.
HTH
--
Joe Fallon
" Bob" <bo*******@yaho o.com> wrote in message
news:eZ******** ******@tk2msftn gp13.phx.gbl... Hmm, that's still not what I was asking. I understand how and where to
properly close a connection, why it should be done, where to set the pool
size and timeout etc. What I'm trying to get at is that, if I have a page
that needs to make a series of calls to the database, say, call SP 1 to
get some data to populate a drop down, then call SP 2 to get some other data
to populate a datagrid, in the same page a user control on the page calls SP
3 to get some status data to display on the sidebar. So I face a design
decision here. One way is to create one instance of the SqlConnection
object (could be handled by a middle tier but for discussion purpose let's
say I'm doing this directly from the aspx.cs class) and use it throughout
the page, and put the .Close() in the page Dispose() method so the
connection is closed at the end and only at the end of the page
processing. Alternatively, I can design it to let each call create its own instance of
the SqlConnection object and close it immediate after the call is done.
This way, I can wrap each call in its self contained function, and
particularly for the user control on the page, I don't have to get the
connection instance from the main page. This makes the code simpler and
the logic a lot easier to follow. However, the second option would use 3
different connections. Assuming the connections are already in the pool
so it doesn't have to create brand new ones, it would be getting and
returning connections to the pool 3 times, rather than 1 in the first option. So
back to my original questions, if getting and returning connections to the pool
has become so efficient that doing it 2 times more is no big deal at all
then I probably should go with option 2, otherwise I should still do
option 1, which has more complicated coding particularly if a middle tier is
involved.
Thanks
"Bin Song, MCP" <an*******@disc ussions.microso ft.com> wrote in message
news:2C******** *************** ***********@mic rosoft.com... Hi, Bob
I understand your question now.
The returning of Connection to pool depend on when you close the connection or the connection time out. The pool size and timeout can be
defined in the connection string. It is recommended that you always close the Connection when you are
finished using it in order for the connection to be returned to the pool.
This can be done using either the Close or Dispose methods of the
Connection object. Connections that are not explicitly closed might not be added or
returned to the pool. For example, a connection that has gone out of scope
but that has not been explicitly closed will only be returned to the
connection pool if the maximum pool size has been reached and the
connection is still valid.
Please see the following article:
http://msdn.microsoft.com/library/de...taProvider.asp
Bin Song, MCP
----- Bob wrote: -----
Alex, thanks for your reply. I understand that the same
connection string reults in connections in the same pool. My question is whether getting and returning connections to the pool have become so efficient in
ADP.NET and Sql Data Provider that there is no need to put in extra code in
order to reduce the number of getting and returning from say, 3 to 1.
Thanks
Bob
"Alex Papadimoulis" <al***@papadimo ulis.com> wrote in message
news:10******** *****@corp.supe rnews.com... > Bob, IIRC, so long as you open the connection with the same connection > string, it'll be pooled.
>> Alex Papadimoulis
> " Bob" <bo*******@yaho o.com> wrote in message
> news:Og******** *****@TK2MSFTNG P11.phx.gbl...
>> In our new .NET web applications, we try to limit the use of
SqlConnection >> to just one instance per page, even if there are multiple
accesses to >> various queries. The thinking behind is that this reduces the need to >> getting and returning connections to the pool repeatedly if a
page has >> multiple calls to the DB, and each one manages its own
connection. > However,
>> this does requires more deliberate coding, like calling the
>> SqlConnection.C lose() method in the page's Dispose() method so
it's >> garanteed that the connection is closed when the page processing is done, >> and also is not closed too early. What I'm thinking is whether
this is >> actually necessary because passing the Connection object into child > controls
>> becomes a pretty big hassle when there are several user controls or custom >> controls on the page. If the connection pool management is very
efficient >> then opening and closing connections repeatly in the code (which
is really >> getting and returning connections to the pool) wouldn't be a big
deal, and >> keeping the code simple would be more important. Could anyone
give some >> suggestions?
>>>>>>
Thanks a lot guys. sounds like you all are saying the 2nd option is better,
that is, open and close immediately as needed, even if it means doing it
several times in one request. I also read some other articles which lead to
similar conclusions.
Thanks again for the help.
Bob
"Joe Fallon" <jf******@nospa mtwcny.rr.com> wrote in message
news:Ol******** ******@TK2MSFTN GP09.phx.gbl... Bob,
You should use a single connection and just open and close as needed.
The connection in the pool is not really closed. It is just sitting there
waiting for you to ask for it again.
So you lose nothing to "close" a connection and the "open" it. It is
already open.
In my Business Objects I open a datareader to populate the BO and then
close it and re-open a 2nd dr to populate any contained BOs or collections. The
dr.close also "closes" the connection but then I re-open it and poulate
the next object.
HTH
--
Joe Fallon
" Bob" <bo*******@yaho o.com> wrote in message
news:eZ******** ******@tk2msftn gp13.phx.gbl... Hmm, that's still not what I was asking. I understand how and where to
properly close a connection, why it should be done, where to set the
pool size and timeout etc. What I'm trying to get at is that, if I have a
page that needs to make a series of calls to the database, say, call SP 1 to get some data to populate a drop down, then call SP 2 to get some other data
to populate a datagrid, in the same page a user control on the page calls
SP 3 to get some status data to display on the sidebar. So I face a design
decision here. One way is to create one instance of the SqlConnection
object (could be handled by a middle tier but for discussion purpose
let's say I'm doing this directly from the aspx.cs class) and use it
throughout the page, and put the .Close() in the page Dispose() method so the
connection is closed at the end and only at the end of the page
processing. Alternatively, I can design it to let each call create its own instance
of the SqlConnection object and close it immediate after the call is done.
This way, I can wrap each call in its self contained function, and
particularly for the user control on the page, I don't have to get the
connection instance from the main page. This makes the code simpler and
the logic a lot easier to follow. However, the second option would use 3
different connections. Assuming the connections are already in the pool
so it doesn't have to create brand new ones, it would be getting and
returning connections to the pool 3 times, rather than 1 in the first option. So
back to my original questions, if getting and returning connections to the
pool has become so efficient that doing it 2 times more is no big deal at all
then I probably should go with option 2, otherwise I should still do
option 1, which has more complicated coding particularly if a middle tier is
involved.
Thanks
"Bin Song, MCP" <an*******@disc ussions.microso ft.com> wrote in message
news:2C******** *************** ***********@mic rosoft.com... Hi, Bob
I understand your question now.
The returning of Connection to pool depend on when you close the
connection or the connection time out. The pool size and timeout can be
defined in the connection string. It is recommended that you always close the Connection when you are
finished using it in order for the connection to be returned to the
pool. This can be done using either the Close or Dispose methods of the
Connection object. Connections that are not explicitly closed might not be added or
returned to the pool. For example, a connection that has gone out of
scope but that has not been explicitly closed will only be returned to the
connection pool if the maximum pool size has been reached and the
connection is still valid.
Please see the following article:
http://msdn.microsoft.com/library/de...taProvider.asp
Bin Song, MCP
----- Bob wrote: -----
Alex, thanks for your reply. I understand that the same connection string reults in connections in the same pool. My question is whether
getting and returning connections to the pool have become so efficient in ADP.NET and Sql Data Provider that there is no need to put in extra code in
order to reduce the number of getting and returning from say, 3 to 1.
Thanks
Bob
"Alex Papadimoulis" <al***@papadimo ulis.com> wrote in message
news:10******** *****@corp.supe rnews.com...
> Bob, IIRC, so long as you open the connection with the same
connection > string, it'll be pooled.
>> Alex Papadimoulis
> " Bob" <bo*******@yaho o.com> wrote in message
> news:Og******** *****@TK2MSFTNG P11.phx.gbl...
>> In our new .NET web applications, we try to limit the use of
SqlConnection
>> to just one instance per page, even if there are multiple
accesses to >> various queries. The thinking behind is that this reduces the
need to >> getting and returning connections to the pool repeatedly if a
page has >> multiple calls to the DB, and each one manages its own
connection. > However,
>> this does requires more deliberate coding, like calling the
>> SqlConnection.C lose() method in the page's Dispose() method so
it's >> garanteed that the connection is closed when the page
processing is done,
>> and also is not closed too early. What I'm thinking is
whether this is >> actually necessary because passing the Connection object into
child > controls
>> becomes a pretty big hassle when there are several user
controls or custom
>> controls on the page. If the connection pool management is
very efficient
>> then opening and closing connections repeatly in the code
(which is really
>> getting and returning connections to the pool) wouldn't be a
big deal, and
>> keeping the code simple would be more important. Could anyone
give some >> suggestions?
>>>>>>
Pooling tends to be very efficient, particularly if you're not using
DTC/COM+ transactions. Integrated security also has an small impact, but is
has been greatly optimized in .NET 1.1.
That said, if you want to squeeze every last bit of performance, keeping the
connection open for the execution of the entire page is certainly better.
While pooling is efficient, there is quite a bit of code that needs to run
in order to grab a connection, and we can potentially hit a lock because of
other threads accessing the pooler.
Regarding the scalability implications of this: is most cases a page is
processed very quickly and "all together" -meaning that there are no long
pauses during the page rendering process. Given that assumption, there is no
benefit on opening/closing the connection at every use within the same page.
--
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corp.
This posting is provided "AS IS" with no warranties, and confers no rights.
" Bob" <bo*******@yaho o.com> wrote in message
news:Og******** *****@TK2MSFTNG P11.phx.gbl... In our new .NET web applications, we try to limit the use of SqlConnection
to just one instance per page, even if there are multiple accesses to
various queries. The thinking behind is that this reduces the need to
getting and returning connections to the pool repeatedly if a page has
multiple calls to the DB, and each one manages its own connection.
However, this does requires more deliberate coding, like calling the
SqlConnection.C lose() method in the page's Dispose() method so it's
garanteed that the connection is closed when the page processing is done,
and also is not closed too early. What I'm thinking is whether this is
actually necessary because passing the Connection object into child
controls becomes a pretty big hassle when there are several user controls or custom
controls on the page. If the connection pool management is very efficient
then opening and closing connections repeatly in the code (which is really
getting and returning connections to the pool) wouldn't be a big deal, and
keeping the code simple would be more important. Could anyone give some
suggestions?
As a third option, consider using the Microsoft Data Access Application
Block, and let it worry about the rest <g>!
" Bob" <bo*******@yaho o.com> wrote in message
news:uC******** ******@TK2MSFTN GP10.phx.gbl... Thanks a lot guys. sounds like you all are saying the 2nd option is
better, that is, open and close immediately as needed, even if it means doing it
several times in one request. I also read some other articles which lead
to similar conclusions.
Thanks again for the help.
Bob
"Joe Fallon" <jf******@nospa mtwcny.rr.com> wrote in message
news:Ol******** ******@TK2MSFTN GP09.phx.gbl... Bob,
You should use a single connection and just open and close as needed.
The connection in the pool is not really closed. It is just sitting
there waiting for you to ask for it again.
So you lose nothing to "close" a connection and the "open" it. It is already open.
In my Business Objects I open a datareader to populate the BO and then
close it and re-open a 2nd dr to populate any contained BOs or collections.
The dr.close also "closes" the connection but then I re-open it and poulate
the next object.
HTH
--
Joe Fallon
" Bob" <bo*******@yaho o.com> wrote in message
news:eZ******** ******@tk2msftn gp13.phx.gbl... Hmm, that's still not what I was asking. I understand how and where
to properly close a connection, why it should be done, where to set the pool size and timeout etc. What I'm trying to get at is that, if I have a page that needs to make a series of calls to the database, say, call SP 1
to get some data to populate a drop down, then call SP 2 to get some other
data to populate a datagrid, in the same page a user control on the page calls SP 3 to get some status data to display on the sidebar. So I face a design
decision here. One way is to create one instance of the
SqlConnection object (could be handled by a middle tier but for discussion purpose
let's say I'm doing this directly from the aspx.cs class) and use it throughout the page, and put the .Close() in the page Dispose() method so the
connection is closed at the end and only at the end of the page
processing. Alternatively, I can design it to let each call create its own
instance of the SqlConnection object and close it immediate after the call is
done. This way, I can wrap each call in its self contained function, and
particularly for the user control on the page, I don't have to get the
connection instance from the main page. This makes the code simpler
and the logic a lot easier to follow. However, the second option would use 3
different connections. Assuming the connections are already in the
pool so it doesn't have to create brand new ones, it would be getting and
returning connections to the pool 3 times, rather than 1 in the first option.
So back to my original questions, if getting and returning connections to the pool has become so efficient that doing it 2 times more is no big deal at
all then I probably should go with option 2, otherwise I should still do
option 1, which has more complicated coding particularly if a middle tier is
involved.
Thanks
"Bin Song, MCP" <an*******@disc ussions.microso ft.com> wrote in message
news:2C******** *************** ***********@mic rosoft.com...
> Hi, Bob
>
> I understand your question now.
> The returning of Connection to pool depend on when you close the
connection or the connection time out. The pool size and timeout can
be defined in the connection string.
> It is recommended that you always close the Connection when you are
finished using it in order for the connection to be returned to the
pool. This can be done using either the Close or Dispose methods of the
Connection object. Connections that are not explicitly closed might not be added
or returned to the pool. For example, a connection that has gone out of scope but that has not been explicitly closed will only be returned to the
connection pool if the maximum pool size has been reached and the
connection is still valid.
>
> Please see the following article:
>
http://msdn.microsoft.com/library/de...taProvider.asp >
> Bin Song, MCP
>
> ----- Bob wrote: -----
>
> Alex, thanks for your reply. I understand that the same
connection string
> reults in connections in the same pool. My question is whether
getting and
> returning connections to the pool have become so efficient in
ADP.NET and
> Sql Data Provider that there is no need to put in extra code in
order to
> reduce the number of getting and returning from say, 3 to 1.
>
> Thanks
> Bob
>
> "Alex Papadimoulis" <al***@papadimo ulis.com> wrote in message
> news:10******** *****@corp.supe rnews.com...
> > Bob, IIRC, so long as you open the connection with the same
connection
> > string, it'll be pooled.
> >> Alex Papadimoulis
> > " Bob" <bo*******@yaho o.com> wrote in message
> > news:Og******** *****@TK2MSFTNG P11.phx.gbl...
> >> In our new .NET web applications, we try to limit the use of
> SqlConnection
> >> to just one instance per page, even if there are multiple
accesses to
> >> various queries. The thinking behind is that this reduces
the need to
> >> getting and returning connections to the pool repeatedly if
a page has
> >> multiple calls to the DB, and each one manages its own
connection. > > However,
> >> this does requires more deliberate coding, like calling the
> >> SqlConnection.C lose() method in the page's Dispose() method
so it's
> >> garanteed that the connection is closed when the page
processing is
> done,
> >> and also is not closed too early. What I'm thinking is whether this is
> >> actually necessary because passing the Connection object
into child
> > controls
> >> becomes a pretty big hassle when there are several user controls or
> custom
> >> controls on the page. If the connection pool management is very > efficient
> >> then opening and closing connections repeatly in the code (which is
> really
> >> getting and returning connections to the pool) wouldn't be a big deal,
> and
> >> keeping the code simple would be more important. Could
anyone give some
> >> suggestions?
> >>>>>>
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Bob |
last post by:
In our new .NET web applications, we try to limit the use of SqlConnection
to just one instance per page, even if there are multiple accesses to
various queries. The thinking behind is that this reduces the need to
getting and returning connections to the pool repeatedly if a page has
multiple calls to the DB, and each one manages its own connection. However,
this does requires more deliberate coding, like calling the...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
| | |
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
