Hello!
After I've finished using an instance of the SqlCommand class, should I then
invoke Dispose() on the instance. I suppose so, as there is a Dispose
method, but what does it actually release?
I would basically prefer to skip invoking Dispose() as this will free me
from determining when the usage actually has finished.
Best regards,
Henrik Dahl
10  18371 
Henrik,
This is a bad design, in my opinion. Generally speaking, with DB operations, at least with the model in .NET (disconnected recordsets), you should open your connection, perform your operation, and get out. You can recreate the command. Also, do you really want to be passing around commands to your database to someone on the outside that might use it in an improper manner?
So, given all that, yes, you should always call Dispose. It doesn't really matter what it disposes, the implication through the implementation (say that 10 times fast) of IDispose is that there is a resource the class manages which should be disposed of in a timely manner as opposed to waiting for a GC.
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- nick(d0t)paldino=At-exisconsulting'dot|com
On Mon, 6 Oct 2003 12:57:18 +0200, Henrik Dahl <Th**********************@inet.uni2.dk> wrote: Hello!
After I've finished using an instance of the SqlCommand class, should I then
invoke Dispose() on the instance. I suppose so, as there is a Dispose
method, but what does it actually release?
I would basically prefer to skip invoking Dispose() as this will free me
from determining when the usage actually has finished.
Best regards,
Henrik Dahl
Hi Henrik,
I'm not very sure that you need to call Dispose() on a SqlCommand , the
Dispose() of SqlCommand is inherited from Component ( according to MSDN )
therefore it does not perform any DB related op.
You should definely close the connection , regarding the SqlCommand this
is what the ADO.NET guide says:
"Although you can repeatedly use the same SqlCommand object to execute the
same command multiple times, do not reuse the same SqlCommand object to
execute different commands. "
Hope this help,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Henrik Dahl" <Th**********************@inet.uni2.dk> wrote in message
news:ev*************@TK2MSFTNGP11.phx.gbl... Hello!
After I've finished using an instance of the SqlCommand class, should I
then invoke Dispose() on the instance. I suppose so, as there is a Dispose
method, but what does it actually release?
I would basically prefer to skip invoking Dispose() as this will free me
from determining when the usage actually has finished.
Best regards,
Henrik Dahl
Hello Ignacio,
Interesting, also because on the SqlCommand overview page it reads:
"You can reset the CommandText property and reuse the SqlCommand object.
However, you must close the SqlDataReader before you can execute a new or
previous command.".
Best regards,
Henrik Dahl
"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:uw**************@TK2MSFTNGP12.phx.gbl... Hi Henrik,
I'm not very sure that you need to call Dispose() on a SqlCommand , the
Dispose() of SqlCommand is inherited from Component ( according to MSDN )
therefore it does not perform any DB related op.
You should definely close the connection , regarding the SqlCommand this
is what the ADO.NET guide says:
"Although you can repeatedly use the same SqlCommand object to execute the
same command multiple times, do not reuse the same SqlCommand object to
execute different commands. "
Hope this help,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Henrik Dahl" <Th**********************@inet.uni2.dk> wrote in message
news:ev*************@TK2MSFTNGP11.phx.gbl... Hello!
After I've finished using an instance of the SqlCommand class, should I
then invoke Dispose() on the instance. I suppose so, as there is a Dispose
method, but what does it actually release?
I would basically prefer to skip invoking Dispose() as this will free me
from determining when the usage actually has finished.
Best regards,
Henrik Dahl
Hi,
Of course you can do it, but it seems that it's not advised, it's like
maintaining open a connection during the live of a application, is doable ,
but not very wise.
The DataReader keeps the connection closed in a way that nobody can reuse
it until it gets close, that's way SqlCommand.ExecuteReader has a overload
that receive a CommandBehavior that you can set it to CloseConnection and it
will automatically close the connection once you close the reader.
Cheers,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Henrik Dahl" <Th**********************@inet.uni2.dk> wrote in message
news:eO**************@TK2MSFTNGP09.phx.gbl... Hello Ignacio,
Interesting, also because on the SqlCommand overview page it reads:
"You can reset the CommandText property and reuse the SqlCommand object.
However, you must close the SqlDataReader before you can execute a new or
previous command.".
Best regards,
Henrik Dahl
"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us>
wrote in message news:uw**************@TK2MSFTNGP12.phx.gbl... Hi Henrik,
I'm not very sure that you need to call Dispose() on a SqlCommand , the
Dispose() of SqlCommand is inherited from Component ( according to
MSDN ) therefore it does not perform any DB related op.
You should definely close the connection , regarding the SqlCommand
this is what the ADO.NET guide says:
"Although you can repeatedly use the same SqlCommand object to execute
the same command multiple times, do not reuse the same SqlCommand object to
execute different commands. "
Hope this help,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Henrik Dahl" <Th**********************@inet.uni2.dk> wrote in message
news:ev*************@TK2MSFTNGP11.phx.gbl... Hello!
After I've finished using an instance of the SqlCommand class, should
I then invoke Dispose() on the instance. I suppose so, as there is a Dispose
method, but what does it actually release?
I would basically prefer to skip invoking Dispose() as this will free
me from determining when the usage actually has finished.
Best regards,
Henrik Dahl
Nicholas,
Obviously I generally agree with you completely. In this particular case I
find it a bit surprising that I've seen many examples of using SqlCommand
objects in documentation from Microsoft, but I've never seen one which
actually Disposes the SqlCommand object afterwards, have you?
Best regards,
Henrik Dahl
"Nicholas Paldino [.NET/C# MVP]" <ni**************@exisconsulting.com> wrote
in message news:op**************@msnews.microsoft.com... Henrik,
This is a bad design, in my opinion. Generally speaking, with DB
operations, at least with the model in .NET (disconnected recordsets), you
should open your connection, perform your operation, and get out. You can
recreate the command. Also, do you really want to be passing around
commands to your database to someone on the outside that might use it in an
improper manner?
So, given all that, yes, you should always call Dispose. It doesn't
really matter what it disposes, the implication through the implementation
(say that 10 times fast) of IDispose is that there is a resource the class
manages which should be disposed of in a timely manner as opposed to waiting
for a GC.
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- nick(d0t)paldino=At-exisconsulting'dot|com
On Mon, 6 Oct 2003 12:57:18 +0200, Henrik Dahl
<Th**********************@inet.uni2.dk> wrote: Hello!
After I've finished using an instance of the SqlCommand class, should I
then invoke Dispose() on the instance. I suppose so, as there is a Dispose
method, but what does it actually release?
I would basically prefer to skip invoking Dispose() as this will free me
from determining when the usage actually has finished.
Best regards,
Henrik Dahl
You should call Dispose on any object that implements IDisposable, this is
very easy to do with C# and the "using" keyword, in other .net languages you
can use the try finally construct to ensure that Dispose gets called. In
general adhering to this basic principle will greatly reduce stress related
problems with your code and may increase performance as it makes cleaning up
smarter.
Something else to think about is that allthough currently the Command may
not be doing anything meaningfull in its dispose method, there is no
guarantee that this will be true for future releases of the framework.
Calling dispose for all disposable objects will greatly enhance the lifetime
of your code.
Hope this helped,
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
"Henrik Dahl" <Th**********************@inet.uni2.dk> wrote in message
news:ev*************@TK2MSFTNGP11.phx.gbl... Hello!
After I've finished using an instance of the SqlCommand class, should I
then invoke Dispose() on the instance. I suppose so, as there is a Dispose
method, but what does it actually release?
I would basically prefer to skip invoking Dispose() as this will free me
from determining when the usage actually has finished.
Best regards,
Henrik Dahl
Angel,
Yes, that's obvious, but how may it then be that there are many, many
examples from Microsoft which do not invoke the Dispose() method of
SqlCommand objects, even examples which include Disposing e.g. the
SqlConnection object?
A question:
In one of the books from Microsoft Press it's stressed that you should
Close(), not Dispose(), an SqlConnection object because Dispose() will close
the connection to MS SQL Server whereas Close() lets the connection to go
back to the pool, i.e. closes the logical connection. In the ".NET Data
Access Architecture Guide" it's claimed that both Close() and Dispose() let
the SqlConnection to go back to the pool. Which is correct?
Best regards,
Henrik Dahl
"Angel Saenz-Badillos[MS]" <an*****@online.microsoft.com> wrote in message
news:uv**************@TK2MSFTNGP12.phx.gbl... You should call Dispose on any object that implements IDisposable, this is
very easy to do with C# and the "using" keyword, in other .net languages
you can use the try finally construct to ensure that Dispose gets called. In
general adhering to this basic principle will greatly reduce stress
related problems with your code and may increase performance as it makes cleaning
up smarter.
Something else to think about is that allthough currently the Command may
not be doing anything meaningfull in its dispose method, there is no
guarantee that this will be true for future releases of the framework.
Calling dispose for all disposable objects will greatly enhance the
lifetime of your code.
Hope this helped,
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights. Please do not send email directly to this alias. This alias is for
newsgroup purposes only.
"Henrik Dahl" <Th**********************@inet.uni2.dk> wrote in message
news:ev*************@TK2MSFTNGP11.phx.gbl... Hello!
After I've finished using an instance of the SqlCommand class, should I
then invoke Dispose() on the instance. I suppose so, as there is a Dispose
method, but what does it actually release?
I would basically prefer to skip invoking Dispose() as this will free me
from determining when the usage actually has finished.
Best regards,
Henrik Dahl
The reason that the samples in the microsoft documentation do not show calls
to Dispose for the SqlCommand object is that, as it has been stated in this
thread, this does nothing. Looking at the ildasm of SqlCommand shows that it
does not override dispose and just inherits it from the base. The person
writing the sample knew this and coded accordingly. I have written some of
the examples in the docs myself and have done the same thing.
The problem is that as the next version of the urt rolls along there are no
guarantees that dispose will keep doing nothing, it is also tedious to
figure out exactly what objects you have to dispose at all costs
(SqlConnection!) and which you can ignore completelly. The general rule of
"if it implements idisposable, dispose it" will always work.
I am familiar with the Quote you mention. This information was based on
outdated information, for Beta 1 the SqlConnection did not implement a
completelly managed pooling solution, instead it relied on Enterprise
services object pooling. There where a number of problems with this
implementation but it was always meant to be temporary, the documentation
was added to the Beta documentation to work arround some issues with Dispose
and it was only fixed by v1.1! (auch, my fault)
Calling Dispose on the SqlConnection does not close the connection to sql
server, the only thing that Dispose does internally is to set the connection
string to null and to call Close if the connection has not already been
closed. The recommended usage (for the same reasons as I am recomending
always calling dispose) is to call using Sqlconnection (which automatically
disposes) and to call connection.Close(), there is no perf penalty for
calling both.
Hope this helps
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
"Henrik Dahl" <Th**********************@inet.uni2.dk> wrote in message
news:OQ**************@TK2MSFTNGP11.phx.gbl... Angel,
Yes, that's obvious, but how may it then be that there are many, many
examples from Microsoft which do not invoke the Dispose() method of
SqlCommand objects, even examples which include Disposing e.g. the
SqlConnection object?
A question:
In one of the books from Microsoft Press it's stressed that you should
Close(), not Dispose(), an SqlConnection object because Dispose() will
close the connection to MS SQL Server whereas Close() lets the connection to go
back to the pool, i.e. closes the logical connection. In the ".NET Data
Access Architecture Guide" it's claimed that both Close() and Dispose()
let the SqlConnection to go back to the pool. Which is correct?
Best regards,
Henrik Dahl
"Angel Saenz-Badillos[MS]" <an*****@online.microsoft.com> wrote in message
news:uv**************@TK2MSFTNGP12.phx.gbl... You should call Dispose on any object that implements IDisposable, this
is very easy to do with C# and the "using" keyword, in other .net languages you can use the try finally construct to ensure that Dispose gets called. In
general adhering to this basic principle will greatly reduce stress
related problems with your code and may increase performance as it makes
cleaning up smarter.
Something else to think about is that allthough currently the Command
may not be doing anything meaningfull in its dispose method, there is no
guarantee that this will be true for future releases of the framework.
Calling dispose for all disposable objects will greatly enhance the
lifetime of your code.
Hope this helped,
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights. Please do not send email directly to this alias. This alias is for
newsgroup purposes only.
"Henrik Dahl" <Th**********************@inet.uni2.dk> wrote in message
news:ev*************@TK2MSFTNGP11.phx.gbl... Hello!
After I've finished using an instance of the SqlCommand class, should
I then invoke Dispose() on the instance. I suppose so, as there is a Dispose
method, but what does it actually release?
I would basically prefer to skip invoking Dispose() as this will free
me from determining when the usage actually has finished.
Best regards,
Henrik Dahl
Angel,
Thank you very much for your precise answer.
Henrik Dahl
"Angel Saenz-Badillos[MS]" <an*****@online.microsoft.com> wrote in message
news:OB**************@TK2MSFTNGP10.phx.gbl... The reason that the samples in the microsoft documentation do not show
calls to Dispose for the SqlCommand object is that, as it has been stated in
this thread, this does nothing. Looking at the ildasm of SqlCommand shows that
it does not override dispose and just inherits it from the base. The person
writing the sample knew this and coded accordingly. I have written some of
the examples in the docs myself and have done the same thing.
The problem is that as the next version of the urt rolls along there are
no guarantees that dispose will keep doing nothing, it is also tedious to
figure out exactly what objects you have to dispose at all costs
(SqlConnection!) and which you can ignore completelly. The general rule of
"if it implements idisposable, dispose it" will always work.
I am familiar with the Quote you mention. This information was based on
outdated information, for Beta 1 the SqlConnection did not implement a
completelly managed pooling solution, instead it relied on Enterprise
services object pooling. There where a number of problems with this
implementation but it was always meant to be temporary, the documentation
was added to the Beta documentation to work arround some issues with
Dispose and it was only fixed by v1.1! (auch, my fault)
Calling Dispose on the SqlConnection does not close the connection to sql
server, the only thing that Dispose does internally is to set the
connection string to null and to call Close if the connection has not already been
closed. The recommended usage (for the same reasons as I am recomending
always calling dispose) is to call using Sqlconnection (which
automatically disposes) and to call connection.Close(), there is no perf penalty for
calling both.
Hope this helps
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights. Please do not send email directly to this alias. This alias is for
newsgroup purposes only.
"Henrik Dahl" <Th**********************@inet.uni2.dk> wrote in message
news:OQ**************@TK2MSFTNGP11.phx.gbl... Angel,
Yes, that's obvious, but how may it then be that there are many, many
examples from Microsoft which do not invoke the Dispose() method of
SqlCommand objects, even examples which include Disposing e.g. the
SqlConnection object?
A question:
In one of the books from Microsoft Press it's stressed that you should
Close(), not Dispose(), an SqlConnection object because Dispose() will close the connection to MS SQL Server whereas Close() lets the connection to
go back to the pool, i.e. closes the logical connection. In the ".NET Data
Access Architecture Guide" it's claimed that both Close() and Dispose()
let the SqlConnection to go back to the pool. Which is correct?
Best regards,
Henrik Dahl
"Angel Saenz-Badillos[MS]" <an*****@online.microsoft.com> wrote in
message news:uv**************@TK2MSFTNGP12.phx.gbl... You should call Dispose on any object that implements IDisposable,
this is very easy to do with C# and the "using" keyword, in other .net
languages you can use the try finally construct to ensure that Dispose gets called.
In general adhering to this basic principle will greatly reduce stress
related problems with your code and may increase performance as it makes
cleaning up smarter.
Something else to think about is that allthough currently the Command
may not be doing anything meaningfull in its dispose method, there is no
guarantee that this will be true for future releases of the framework.
Calling dispose for all disposable objects will greatly enhance the
lifetime of your code.
Hope this helped,
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights. Please do not send email directly to this alias. This alias is for
newsgroup purposes only.
"Henrik Dahl" <Th**********************@inet.uni2.dk> wrote in message
news:ev*************@TK2MSFTNGP11.phx.gbl...
> Hello!
>
> After I've finished using an instance of the SqlCommand class,
should I then
> invoke Dispose() on the instance. I suppose so, as there is a
Dispose > method, but what does it actually release?
>
> I would basically prefer to skip invoking Dispose() as this will
free me > from determining when the usage actually has finished.
>
>
> Best regards,
>
> Henrik Dahl
>
>
I apologize if my answer seems brusque, I was trying to convey that
disposing Idisposable objects is always a good thing, it is by no means
necesary.
Objects that do not require dispose to be called on today should continue to
work as such for existing code, we will treat any changes in this behavior
as a bug. My hope is that we can avoid any such bugs going forward but
realistically there may be instances where this does not happen, there may
also be cases where new features that use an object that does not require
dispose today may require or benefit from the object being disposed in the
future, this may make things even more confusing.
I guess my question is what kind of examples would you be interested to see
in the documentation that ships with the next version of the URT? How do you
rate your experience with the current batch of samples and how much would it
help if they were to be rewritten? One of the biggest problems with samples
is that VB.NET does not support the "using" keyword, so equivalent C# and
VB.NET samples become less clear, would this be a concern when looking at
doc samples?
looking forward to any doc related feedback
Thanks,
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
"Henrik Dahl" <Th**********************@inet.uni2.dk> wrote in message
news:uv**************@tk2msftngp13.phx.gbl... Angel,
Thank you very much for your precise answer.
Henrik Dahl
"Angel Saenz-Badillos[MS]" <an*****@online.microsoft.com> wrote in message
news:OB**************@TK2MSFTNGP10.phx.gbl... The reason that the samples in the microsoft documentation do not show calls to Dispose for the SqlCommand object is that, as it has been stated in
this thread, this does nothing. Looking at the ildasm of SqlCommand shows
that it does not override dispose and just inherits it from the base. The person
writing the sample knew this and coded accordingly. I have written some
of the examples in the docs myself and have done the same thing.
The problem is that as the next version of the urt rolls along there are no guarantees that dispose will keep doing nothing, it is also tedious to
figure out exactly what objects you have to dispose at all costs
(SqlConnection!) and which you can ignore completelly. The general rule
of "if it implements idisposable, dispose it" will always work.
I am familiar with the Quote you mention. This information was based on
outdated information, for Beta 1 the SqlConnection did not implement a
completelly managed pooling solution, instead it relied on Enterprise
services object pooling. There where a number of problems with this
implementation but it was always meant to be temporary, the
documentation was added to the Beta documentation to work arround some issues with
Dispose and it was only fixed by v1.1! (auch, my fault)
Calling Dispose on the SqlConnection does not close the connection to
sql server, the only thing that Dispose does internally is to set the
connection string to null and to call Close if the connection has not already been
closed. The recommended usage (for the same reasons as I am recomending
always calling dispose) is to call using Sqlconnection (which
automatically disposes) and to call connection.Close(), there is no perf penalty for
calling both.
Hope this helps
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights. Please do not send email directly to this alias. This alias is for
newsgroup purposes only.
"Henrik Dahl" <Th**********************@inet.uni2.dk> wrote in message
news:OQ**************@TK2MSFTNGP11.phx.gbl... Angel,
Yes, that's obvious, but how may it then be that there are many, many
examples from Microsoft which do not invoke the Dispose() method of
SqlCommand objects, even examples which include Disposing e.g. the
SqlConnection object?
A question:
In one of the books from Microsoft Press it's stressed that you should
Close(), not Dispose(), an SqlConnection object because Dispose() will
close the connection to MS SQL Server whereas Close() lets the connection to go back to the pool, i.e. closes the logical connection. In the ".NET
Data Access Architecture Guide" it's claimed that both Close() and
Dispose() let the SqlConnection to go back to the pool. Which is correct?
Best regards,
Henrik Dahl
"Angel Saenz-Badillos[MS]" <an*****@online.microsoft.com> wrote in message news:uv**************@TK2MSFTNGP12.phx.gbl...
> You should call Dispose on any object that implements IDisposable, this is > very easy to do with C# and the "using" keyword, in other .net languages you
> can use the try finally construct to ensure that Dispose gets
called. In > general adhering to this basic principle will greatly reduce stress
related
> problems with your code and may increase performance as it makes
cleaning up
> smarter.
>
> Something else to think about is that allthough currently the
Command may > not be doing anything meaningfull in its dispose method, there is no
> guarantee that this will be true for future releases of the
framework. > Calling dispose for all disposable objects will greatly enhance the
lifetime
> of your code.
>
> Hope this helped,
> --
> Angel Saenz-Badillos [MS] Managed Providers
> This posting is provided "AS IS", with no warranties, and confers no
rights.
> Please do not send email directly to this alias. This alias is for
newsgroup
> purposes only.
> "Henrik Dahl" <Th**********************@inet.uni2.dk> wrote in
message > news:ev*************@TK2MSFTNGP11.phx.gbl...
> > Hello!
> >
> > After I've finished using an instance of the SqlCommand class,
should I > then
> > invoke Dispose() on the instance. I suppose so, as there is a
Dispose > > method, but what does it actually release?
> >
> > I would basically prefer to skip invoking Dispose() as this will
free me > > from determining when the usage actually has finished.
> >
> >
> > Best regards,
> >
> > Henrik Dahl
> >
> >
>
>
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Daniel Billingsley |
last post by:
Does this look right? I want to be a good boy and dispose of everything and
I'm trying to make sure I have the lifecycles right to support the
transactional part.
using (SqlConnection cn = new...
|
by: bozzzza |
last post by:
If I did something like this :-
=======================================================================================
//Method to return a ref to an SqlConnection
private SqlConnection...
|
by: Bob Lehmann |
last post by:
Hi,
My understanding is that Dispose() should not be used for destroying a
connection object, and that Close() is preferred.
However, in one of MS's Quickstart Apps I see this being used....
...
|
by: ypul |
last post by:
the code below given is connection class ... now I want to use the
connection in another class , by using the getConnection method.
where should I call con.dispose() ?
in connection class or...
|
by: Dennis |
last post by:
Ok, I'm trying to dispose of every object that I create that has a dispose
method based on advice from this newsgroup. However, I'm not sure how to
dispose of the following object that was created...
| | |
by: Agnes |
last post by:
Silly question again. I found that Even I run Sqlcommand.dispose,
I still can use it , does anyone know ?
|
by: Michael Carr |
last post by:
I recently discovered the "using" C# keyword and the neat and tidy way it
guarantees cleanup of resources. However, how far should I take this? I
recall some discussion from Microsoft suggesting...
|
by: demon |
last post by:
I'm having this class
Public Class TestClass
Implements IDisposable
Dim Conn As SqlConnection
Public Sub New(ByVal connectionString As String)
|
by: cj |
last post by:
When I make a request of our sql server I Dim A New SqlConnection and I
Dim A New SqlCommand. The sqlcommand gets it's connection property set
to the sqlconnection. I've recently read the I need...
|
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,...
|
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,...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
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,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
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...
|
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 ...
| |
