Do Named Pipes work across a WAN?

Hi,
Do Named Pipes work across a WAN?
Are they carried on TCP/IP? What ports?
Thanks,
SA Dev
Hi
Windows 2000 and 2003 encapsulate the data in networking layer TCP/IP
packets. Named pipes is not efficient on slow connections.
Your best option is to use TCP/IP sockets.
Once you have firewalls in place, TCP/IP sockets is your only option.
http://support.microsoft.com/default...b;en-us;287932
http://support.microsoft.com/kb/269882/EN-US/
http://msdn.microsoft.com/library/de...setup_77g3.asp
Regards
Mike
"SA Development" wrote:

> Hi,
> Do Named Pipes work across a WAN?
> Are they carried on TCP/IP? What ports?
> Thanks,
> SA Dev
>
>
|||Hi Mike,

> Windows 2000 and 2003 encapsulate the data in networking layer TCP/IP
> packets. Named pipes is not efficient on slow connections.
> Your best option is to use TCP/IP sockets.
> Once you have firewalls in place, TCP/IP sockets is your only option.
Can you use windows authentication with TCP/IP or does it support SQL auth
only?
Does Named Pipes support both windows and sql auth?
Thanks,
SA Dev

Do Named Pipes work across a WAN?

Hi,
Do Named Pipes work across a WAN?
Are they carried on TCP/IP? What ports?
Thanks,
SA DevHi
Windows 2000 and 2003 encapsulate the data in networking layer TCP/IP
packets. Named pipes is not efficient on slow connections.
Your best option is to use TCP/IP sockets.
Once you have firewalls in place, TCP/IP sockets is your only option.
http://support.microsoft.com/default.aspx?scid=kb;en-us;287932
http://support.microsoft.com/kb/269882/EN-US
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/instsql/in_runsetup_77g3.asp
Regards
Mike
"SA Development" wrote:
> Hi,
> Do Named Pipes work across a WAN?
> Are they carried on TCP/IP? What ports?
> Thanks,
> SA Dev
>
>|||Hi Mike,
> Windows 2000 and 2003 encapsulate the data in networking layer TCP/IP
> packets. Named pipes is not efficient on slow connections.
> Your best option is to use TCP/IP sockets.
> Once you have firewalls in place, TCP/IP sockets is your only option.
Can you use windows authentication with TCP/IP or does it support SQL auth
only?
Does Named Pipes support both windows and sql auth?
Thanks,
SA Dev

Do Named Pipes work across a WAN?

Hi,
Do Named Pipes work across a WAN?
Are they carried on TCP/IP? What ports?
Thanks,
SA DevHi
Windows 2000 and 2003 encapsulate the data in networking layer TCP/IP
packets. Named pipes is not efficient on slow connections.
Your best option is to use TCP/IP sockets.
Once you have firewalls in place, TCP/IP sockets is your only option.
http://support.microsoft.com/defaul...kb;en-us;287932
http://support.microsoft.com/kb/269882/EN-US/
http://msdn.microsoft.com/library/d.../>
up_77g3.asp
Regards
Mike
"SA Development" wrote:

> Hi,
> Do Named Pipes work across a WAN?
> Are they carried on TCP/IP? What ports?
> Thanks,
> SA Dev
>
>|||Hi Mike,

> Windows 2000 and 2003 encapsulate the data in networking layer TCP/IP
> packets. Named pipes is not efficient on slow connections.
> Your best option is to use TCP/IP sockets.
> Once you have firewalls in place, TCP/IP sockets is your only option.
Can you use windows authentication with TCP/IP or does it support SQL auth
only?
Does Named Pipes support both windows and sql auth?
Thanks,
SA Devsql

Distributed transactions: ITransactionJoin error on two 2003 Servers

I'm hoping someone can help me, I am trying to start a distributed
transaction across a linked server. Both servers are Windows 2003 (pre
SP1) servers, and both are running SQL Server 2000 SP3a. I am getting
the following error message:
Server: Msg 7391, Level 16, State 1, Line 4
The operation could not be performed because the OLE DB provider
'SQLOLEDB' was unable to begin a distributed transaction.
[OLE/DB provider returned message: New transaction cannot enlist in the
specified transaction coordinator. ]
OLE DB error trace [OLE/DB Provider 'SQLOLEDB'
ITransactionJoin::JoinTransaction returned 0x8004d00a].
I have checked loads of KB articles, and other newsgroup answers and
have come up with the following ideas, all of which I've done on both
machines:
1. Enabled network DTC access on both machines
2. Ensured network and XA transactions are checked in security
configuration
3. Ensured DTC is running on both machines
4. Set the port ranges to 5000-5020 in COM Internet Services Properites
(although firewall is off)
5. Ensured both machines can ping each other by Netbios names
6. Turned off RPC Security on both machines (setting in registry)
7. Set on RPC and RPC Out in Linked server settings
8. Rebooted (many times) both machines
If anyone has any other ideas I can try (apart from changing the code,
as we have to do things this way, it's not all our code) then let me
know as I am pretty much stuck.
Thanks for your help!
Aron Cox,
Hampshire, UK
I am working in the same problem. See KB839279. If you change
Transaction Manager Communication to "No Authentication Required" it
works but your not authenticating. I also read somewhere that changing
the account from Network Service to Local System, it may work.
*** Sent via Developersdex http://www.codecomments.com ***

Distributed transactions: ITransactionJoin error on two 2003 Servers

I'm hoping someone can help me, I am trying to start a distributed
transaction across a linked server. Both servers are Windows 2003 (pre
SP1) servers, and both are running SQL Server 2000 SP3a. I am getting
the following error message:
Server: Msg 7391, Level 16, State 1, Line 4
The operation could not be performed because the OLE DB provider
'SQLOLEDB' was unable to begin a distributed transaction.
[OLE/DB provider returned message: New transaction cannot enlist in the
specified transaction coordinator. ]
OLE DB error trace [OLE/DB Provider 'SQLOLEDB'
ITransactionJoin::JoinTransaction returned 0x8004d00a].
I have checked loads of KB articles, and other newsgroup answers and
have come up with the following ideas, all of which I've done on both
machines:
1. Enabled network DTC access on both machines
2. Ensured network and XA transactions are checked in security
configuration
3. Ensured DTC is running on both machines
4. Set the port ranges to 5000-5020 in COM Internet Services Properites
(although firewall is off)
5. Ensured both machines can ping each other by Netbios names
6. Turned off RPC Security on both machines (setting in registry)
7. Set on RPC and RPC Out in Linked server settings
8. Rebooted (many times) both machines
If anyone has any other ideas I can try (apart from changing the code,
as we have to do things this way, it's not all our code) then let me
know as I am pretty much stuck.
Thanks for your help!
Aron Cox,
Hampshire, UKI am working in the same problem. See KB839279. If you change
Transaction Manager Communication to "No Authentication Required" it
works but your not authenticating. I also read somewhere that changing
the account from Network Service to Local System, it may work.
*** Sent via Developersdex http://www.codecomments.com ***

Distributed transactions: ITransactionJoin error on two 2003 Servers

I'm hoping someone can help me, I am trying to start a distributed
transaction across a linked server. Both servers are Windows 2003 (pre
SP1) servers, and both are running SQL Server 2000 SP3a. I am getting
the following error message:
Server: Msg 7391, Level 16, State 1, Line 4
The operation could not be performed because the OLE DB provider
'SQLOLEDB' was unable to begin a distributed transaction.
[OLE/DB provider returned message: New transaction cannot enlist in the
specified transaction coordinator. ]
OLE DB error trace [OLE/DB Provider 'SQLOLEDB'
ITransactionJoin::JoinTransaction returned 0x8004d00a].
I have checked loads of KB articles, and other newsgroup answers and
have come up with the following ideas, all of which I've done on both
machines:
1. Enabled network DTC access on both machines
2. Ensured network and XA transactions are checked in security
configuration
3. Ensured DTC is running on both machines
4. Set the port ranges to 5000-5020 in COM Internet Services Properites
(although firewall is off)
5. Ensured both machines can ping each other by Netbios names
6. Turned off RPC Security on both machines (setting in registry)
7. Set on RPC and RPC Out in Linked server settings
8. Rebooted (many times) both machines
If anyone has any other ideas I can try (apart from changing the code,
as we have to do things this way, it's not all our code) then let me
know as I am pretty much stuck.
Thanks for your help!
Aron Cox,
Hampshire, UKI am working in the same problem. See KB839279. If you change
Transaction Manager Communication to "No Authentication Required" it
works but your not authenticating. I also read somewhere that changing
the account from Network Service to Local System, it may work.
*** Sent via Developersdex http://www.developersdex.com ***

Distributed Scenario...

Hi ,
We're building a windows app and using SQL 2005.
The scenario is this.
Our app will be spread across various geographical locations.
The information is more or less location specific i.e. a user in one
loaction will probably not require to see/modify the data in another
location. We are looking at huge volumes of data and the connectivity
could be pretty decent.
Do we
1. Go with one centralised server?
2. Go with a server for each location.
In this scenario what would be the impact on the cost.
3. Go with Point 2 but also have one centralised server which will sink
up data from all locations. Is this suggested? If so does SQL server
have some kind of automatic sync utility or services which can be say
run at a particular time?
4. I do not have much info on Mirroring but will this help if I were to
use a centralised server.?
Thanks in advance
Soni
I cant be certain without having some more info regarding size and req for
your scenario. I would probably use option 3 and yes, you can maintain
centralised server through replication or SSIS or some other feature
depending on your needs.
As for the 4) Mirroring will not be available untill mid 2006 and it could
help, again depending on what would you want to do on the centralised
server...
MC
"hangar18" <soni.somarajan@.wipro.com> wrote in message
news:1133250860.462491.247260@.f14g2000cwb.googlegr oups.com...
> Hi ,
> We're building a windows app and using SQL 2005.
> The scenario is this.
> Our app will be spread across various geographical locations.
> The information is more or less location specific i.e. a user in one
> loaction will probably not require to see/modify the data in another
> location. We are looking at huge volumes of data and the connectivity
> could be pretty decent.
> Do we
> 1. Go with one centralised server?
> 2. Go with a server for each location.
> In this scenario what would be the impact on the cost.
> 3. Go with Point 2 but also have one centralised server which will sink
> up data from all locations. Is this suggested? If so does SQL server
> have some kind of automatic sync utility or services which can be say
> run at a particular time?
> 4. I do not have much info on Mirroring but will this help if I were to
> use a centralised server.?
> Thanks in advance
> Soni
>

Distributed Scenario...

Hi ,
We're building a windows app and using SQL 2005.
The scenario is this.
Our app will be spread across various geographical locations.
The information is more or less location specific i.e. a user in one
loaction will probably not require to see/modify the data in another
location. We are looking at huge volumes of data and the connectivity
could be pretty decent.
Do we
1. Go with one centralised server?
2. Go with a server for each location.
In this scenario what would be the impact on the cost.
3. Go with Point 2 but also have one centralised server which will sink
up data from all locations. Is this suggested? If so does SQL server
have some kind of automatic sync utility or services which can be say
run at a particular time?
4. I do not have much info on Mirroring but will this help if I were to
use a centralised server.?
Thanks in advance
SoniI cant be certain without having some more info regarding size and req for
your scenario. I would probably use option 3 and yes, you can maintain
centralised server through replication or SSIS or some other feature
depending on your needs.
As for the 4) Mirroring will not be available untill mid 2006 and it could
help, again depending on what would you want to do on the centralised
server...
MC
"hangar18" <soni.somarajan@.wipro.com> wrote in message
news:1133250860.462491.247260@.f14g2000cwb.googlegroups.com...
> Hi ,
> We're building a windows app and using SQL 2005.
> The scenario is this.
> Our app will be spread across various geographical locations.
> The information is more or less location specific i.e. a user in one
> loaction will probably not require to see/modify the data in another
> location. We are looking at huge volumes of data and the connectivity
> could be pretty decent.
> Do we
> 1. Go with one centralised server?
> 2. Go with a server for each location.
> In this scenario what would be the impact on the cost.
> 3. Go with Point 2 but also have one centralised server which will sink
> up data from all locations. Is this suggested? If so does SQL server
> have some kind of automatic sync utility or services which can be say
> run at a particular time?
> 4. I do not have much info on Mirroring but will this help if I were to
> use a centralised server.?
> Thanks in advance
> Soni
>

Distributed Scenario...

Hi ,
We're building a windows app and using SQL 2005.
The scenario is this.
Our app will be spread across various geographical locations.
The information is more or less location specific i.e. a user in one
loaction will probably not require to see/modify the data in another
location. We are looking at huge volumes of data and the connectivity
could be pretty decent.
Do we
1. Go with one centralised server?
2. Go with a server for each location.
In this scenario what would be the impact on the cost.
3. Go with Point 2 but also have one centralised server which will sink
up data from all locations. Is this suggested? If so does SQL server
have some kind of automatic sync utility or services which can be say
run at a particular time?
4. I do not have much info on Mirroring but will this help if I were to
use a centralised server.?
Thanks in advance
SoniI cant be certain without having some more info regarding size and req for
your scenario. I would probably use option 3 and yes, you can maintain
centralised server through replication or SSIS or some other feature
depending on your needs.
As for the 4) Mirroring will not be available untill mid 2006 and it could
help, again depending on what would you want to do on the centralised
server...
MC
"hangar18" <soni.somarajan@.wipro.com> wrote in message
news:1133250860.462491.247260@.f14g2000cwb.googlegroups.com...
> Hi ,
> We're building a windows app and using SQL 2005.
> The scenario is this.
> Our app will be spread across various geographical locations.
> The information is more or less location specific i.e. a user in one
> loaction will probably not require to see/modify the data in another
> location. We are looking at huge volumes of data and the connectivity
> could be pretty decent.
> Do we
> 1. Go with one centralised server?
> 2. Go with a server for each location.
> In this scenario what would be the impact on the cost.
> 3. Go with Point 2 but also have one centralised server which will sink
> up data from all locations. Is this suggested? If so does SQL server
> have some kind of automatic sync utility or services which can be say
> run at a particular time?
> 4. I do not have much info on Mirroring but will this help if I were to
> use a centralised server.?
> Thanks in advance
> Soni
>