G
gentlerobbin
The pretty 80, just my random guess if that is going to soothe your
feeling.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
The pretty 80, just my random guess if that is going to soothe your
feeling.
G
gentlerobbin
Does anyone jnow which ports and protocol(tcp or udp) Ado.Net uses?
Can Ichange it and how?
Regards
Ragid
The pretty 80, just my random guess if that is going to soothe your
feeling.
A
Alberto Poblacion
Ragid said:Does anyone jnow which ports and protocol(tcp or udp) Ado.Net uses?
Can Ichange it and how?
ADO.NET itself doesn't use any ports. You could, for instance, create a
DataTable in memory and manipulate it in code without ever using any port at
all.
If you use ADO.NET to connect to a database, then the ports used would
depend on the database client. For instance, if you use the OleDb client to
access the JET engine to open an Access database, then no ports will be used
(if it is a local file), since the file wll be opened locally on the
filesystem.
If you use the SqlClient to access a SQL Server database, then the
ports in use will depend on the connection string and the configuration of
the Sql client. If you connect to "(local)", then the shared memory provider
will be used, which doesn't use any tcp or udp ports. On the other hand, if
you connect to a given server, and the client is installed with its default
configuration, it will attempt to connect on port TCP 1433. This can be
changed with the Sql Server configuration tools, but note that this happens
entirely outside of ADO.NET.
A
Alberto Poblacion
Ragid said:Does anyone jnow which ports and protocol(tcp or udp) Ado.Net uses?
Can Ichange it and how?
ADO.NET itself doesn't use any ports. You could, for instance, create a
DataTable in memory and manipulate it in code without ever using any port at
all.
If you use ADO.NET to connect to a database, then the ports used would
depend on the database client. For instance, if you use the OleDb client to
access the JET engine to open an Access database, then no ports will be used
(if it is a local file), since the file wll be opened locally on the
filesystem.
If you use the SqlClient to access a SQL Server database, then the
ports in use will depend on the connection string and the configuration of
the Sql client. If you connect to "(local)", then the shared memory provider
will be used, which doesn't use any tcp or udp ports. On the other hand, if
you connect to a given server, and the client is installed with its default
configuration, it will attempt to connect on port TCP 1433. This can be
changed with the Sql Server configuration tools, but note that this happens
entirely outside of ADO.NET.
R
Ragid
Does anyone jnow which ports and protocol(tcp or udp) Ado.Net uses?
Can Ichange it and how?
Regards
Ragid
Can Ichange it and how?
Regards
Ragid
R
redtooth.yellowtooth.tooth
ADO.NET itself doesn't use any ports. You could, for instance, create a
DataTable in memory and manipulate it in code without ever using any portat
all.
If you use ADO.NET to connect to a database, then the ports used would
depend on the database client. For instance, if you use the OleDb client to
access the JET engine to open an Access database, then no ports will be used
(if it is a local file), since the file wll be opened locally on the
filesystem.
If you use the SqlClient to access a SQL Server database, thenthe
ports in use will depend on the connection string and the configuration of
the Sql client. If you connect to "(local)", then the shared memory provider
will be used, which doesn't use any tcp or udp ports. On the other hand, if
you connect to a given server, and the client is installed with its default
configuration, it will attempt to connect on port TCP 1433. This can be
changed with the Sql Server configuration tools, but note that this happens
entirely outside of ADO.NET.
Right, but 80 is my favorite for web application after all and seem to
be a must in my case. 80 is the coolest port hehehe
R
redtooth.yellowtooth.tooth
ADO.NET itself doesn't use any ports. You could, for instance, create a
DataTable in memory and manipulate it in code without ever using any portat
all.
If you use ADO.NET to connect to a database, then the ports used would
depend on the database client. For instance, if you use the OleDb client to
access the JET engine to open an Access database, then no ports will be used
(if it is a local file), since the file wll be opened locally on the
filesystem.
If you use the SqlClient to access a SQL Server database, thenthe
ports in use will depend on the connection string and the configuration of
the Sql client. If you connect to "(local)", then the shared memory provider
will be used, which doesn't use any tcp or udp ports. On the other hand, if
you connect to a given server, and the client is installed with its default
configuration, it will attempt to connect on port TCP 1433. This can be
changed with the Sql Server configuration tools, but note that this happens
entirely outside of ADO.NET.
Right, but 80 is my favorite for web application after all and seem to
be a must in my case. 80 is the coolest port hehehe
P
Paul
It is the resource you are accessing that will determine what ports ADO uses
if any.
If we are talking SQL Server than the default port is 1433 when using TCP/IP
but can be changed so you may want to check with your DBA, however if using
named pipes its 139 or 445 or both.
SQL Server I believe uses TCP/IP, UDP is fire and forget so you would never
know if that packet sent to update the DB actually ever arrived. But do not
take my word on that you may want to check on MSDN.
If you need to cross firewall boundries consider using SOAP to abstract your
BLL interfaces and prevent access to the DB direct from public facing
environments by opening firwall ports.
if any.
If we are talking SQL Server than the default port is 1433 when using TCP/IP
but can be changed so you may want to check with your DBA, however if using
named pipes its 139 or 445 or both.
SQL Server I believe uses TCP/IP, UDP is fire and forget so you would never
know if that packet sent to update the DB actually ever arrived. But do not
take my word on that you may want to check on MSDN.
If you need to cross firewall boundries consider using SOAP to abstract your
BLL interfaces and prevent access to the DB direct from public facing
environments by opening firwall ports.
P
Paul
It is the resource you are accessing that will determine what ports ADO uses
if any.
If we are talking SQL Server than the default port is 1433 when using TCP/IP
but can be changed so you may want to check with your DBA, however if using
named pipes its 139 or 445 or both.
SQL Server I believe uses TCP/IP, UDP is fire and forget so you would never
know if that packet sent to update the DB actually ever arrived. But do not
take my word on that you may want to check on MSDN.
If you need to cross firewall boundries consider using SOAP to abstract your
BLL interfaces and prevent access to the DB direct from public facing
environments by opening firwall ports.
if any.
If we are talking SQL Server than the default port is 1433 when using TCP/IP
but can be changed so you may want to check with your DBA, however if using
named pipes its 139 or 445 or both.
SQL Server I believe uses TCP/IP, UDP is fire and forget so you would never
know if that packet sent to update the DB actually ever arrived. But do not
take my word on that you may want to check on MSDN.
If you need to cross firewall boundries consider using SOAP to abstract your
BLL interfaces and prevent access to the DB direct from public facing
environments by opening firwall ports.