I have read that Named pipes work faster/better in a LAN environment ? I
have a question.. so would it make sense if the Web Servers (IIS on Windows
2000) that talk to the database servers on the same LAN communicate via
Named pipes as opposed to TCPIP . Also same with regards to the business
tier thats also on the same LAN that talks to the databases that can
communicate using Named pipes
Please provide your inputs here . Currently we use TCPIP. Using SQL 2000HASSAN AFTER READING THIS YOU BE THE JUDGE
Named Pipes vs. TCP/IP Sockets
In a fast local area network (LAN) environment, Transmission Control
Protocol/Internet Protocol (TCP/IP) Sockets and Named Pipes clients are
comparable in terms of performance. However, the performance difference
between the TCP/IP Sockets and Named Pipes clients becomes apparent with
slower networks, such as across wide area networks (WANs) or dial-up
networks. This is because of the different ways the interprocess
communication (IPC) mechanisms communicate between peers.
For named pipes, network communications are typically more interactive. A
peer does not send data until another peer asks for it using a read command.
A network read typically involves a series of peek named pipes messages
before it begins to read the data. These can be very costly in a slow
network and cause excessive network traffic, which in turn affects other
network clients.
It is also important to clarify if you are talking about local pipes or
network pipes. If the server application is running locally on the computer
running an instance of Microsoft SQL ServerT 2000, the local Named Pipes
protocol is an option. Local named pipes runs in kernel mode and is
extremely fast.
For TCP/IP Sockets, data transmissions are more streamlined and have less
overhead. Data transmissions can also take advantage of TCP/IP Sockets
performance enhancement mechanisms such as windowing, delayed
acknowledgements, and so on, which can be very beneficial in a slow network.
Depending on the type of applications, such performance differences can be
significant.
TCP/IP Sockets also support a backlog queue, which can provide a limited
smoothing effect compared to named pipes that may lead to pipe busy errors
when you are attempting to connect to SQL Server.
In general, sockets are preferred in a slow LAN, WAN, or dial-up network,
whereas named pipes can be a better choice when network speed is not the
issue, as it offers more functionality, ease of use, and configuration
options.
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:ORNMyEE8DHA.3360@.tk2msftngp13.phx.gbl...
> I have read that Named pipes work faster/better in a LAN environment ? I
> have a question.. so would it make sense if the Web Servers (IIS on
Windows
> 2000) that talk to the database servers on the same LAN communicate via
> Named pipes as opposed to TCPIP . Also same with regards to the business
> tier thats also on the same LAN that talks to the databases that can
> communicate using Named pipes
> Please provide your inputs here . Currently we use TCPIP. Using SQL 2000
>
Showing posts with label environment. Show all posts
Showing posts with label environment. Show all posts
Wednesday, March 28, 2012
Named Pipes or TCP IP in LAN
I have read that Named pipes work faster/better in a LAN environment ? I
have a question.. so would it make sense if the Web Servers (IIS on Windows
2000) that talk to the database servers on the same LAN communicate via
Named pipes as opposed to TCPIP . Also same with regards to the business
tier thats also on the same LAN that talks to the databases that can
communicate using Named pipes
Please provide your inputs here . Currently we use TCPIP. Using SQL 2000HASSAN AFTER READING THIS YOU BE THE JUDGE
Named Pipes vs. TCP/IP Sockets
In a fast local area network (LAN) environment, Transmission Control
Protocol/Internet Protocol (TCP/IP) Sockets and Named Pipes clients are
comparable in terms of performance. However, the performance difference
between the TCP/IP Sockets and Named Pipes clients becomes apparent with
slower networks, such as across wide area networks (WANs) or dial-up
networks. This is because of the different ways the interprocess
communication (IPC) mechanisms communicate between peers.
For named pipes, network communications are typically more interactive. A
peer does not send data until another peer asks for it using a read command.
A network read typically involves a series of peek named pipes messages
before it begins to read the data. These can be very costly in a slow
network and cause excessive network traffic, which in turn affects other
network clients.
It is also important to clarify if you are talking about local pipes or
network pipes. If the server application is running locally on the computer
running an instance of Microsoft® SQL ServerT 2000, the local Named Pipes
protocol is an option. Local named pipes runs in kernel mode and is
extremely fast.
For TCP/IP Sockets, data transmissions are more streamlined and have less
overhead. Data transmissions can also take advantage of TCP/IP Sockets
performance enhancement mechanisms such as windowing, delayed
acknowledgements, and so on, which can be very beneficial in a slow network.
Depending on the type of applications, such performance differences can be
significant.
TCP/IP Sockets also support a backlog queue, which can provide a limited
smoothing effect compared to named pipes that may lead to pipe busy errors
when you are attempting to connect to SQL Server.
In general, sockets are preferred in a slow LAN, WAN, or dial-up network,
whereas named pipes can be a better choice when network speed is not the
issue, as it offers more functionality, ease of use, and configuration
options.
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:ORNMyEE8DHA.3360@.tk2msftngp13.phx.gbl...
> I have read that Named pipes work faster/better in a LAN environment ? I
> have a question.. so would it make sense if the Web Servers (IIS on
Windows
> 2000) that talk to the database servers on the same LAN communicate via
> Named pipes as opposed to TCPIP . Also same with regards to the business
> tier thats also on the same LAN that talks to the databases that can
> communicate using Named pipes
> Please provide your inputs here . Currently we use TCPIP. Using SQL 2000
>|||Another thing to consider with Named Pipes is that the
user's Windows user accounts must have permission to
establish a NetBEUI connection to the Windows box that
SQL Server is running on. This is not the case when
using TCP/IP Sockets.
Just out of curiosity, where did you read that Named
Pipes was faster/better in a LAN environment? The last
time I experienced Named Pipes to be noticeably faster
was with a 16 bit client.
Matthew Bando
matthew.bando@.CSCTGI(Remove this).com
>--Original Message--
>I have read that Named pipes work faster/better in a LAN
environment ? I
>have a question.. so would it make sense if the Web
Servers (IIS on Windows
>2000) that talk to the database servers on the same LAN
communicate via
>Named pipes as opposed to TCPIP . Also same with regards
to the business
>tier thats also on the same LAN that talks to the
databases that can
>communicate using Named pipes
>Please provide your inputs here . Currently we use
TCPIP. Using SQL 2000
>
>.
>
have a question.. so would it make sense if the Web Servers (IIS on Windows
2000) that talk to the database servers on the same LAN communicate via
Named pipes as opposed to TCPIP . Also same with regards to the business
tier thats also on the same LAN that talks to the databases that can
communicate using Named pipes
Please provide your inputs here . Currently we use TCPIP. Using SQL 2000HASSAN AFTER READING THIS YOU BE THE JUDGE
Named Pipes vs. TCP/IP Sockets
In a fast local area network (LAN) environment, Transmission Control
Protocol/Internet Protocol (TCP/IP) Sockets and Named Pipes clients are
comparable in terms of performance. However, the performance difference
between the TCP/IP Sockets and Named Pipes clients becomes apparent with
slower networks, such as across wide area networks (WANs) or dial-up
networks. This is because of the different ways the interprocess
communication (IPC) mechanisms communicate between peers.
For named pipes, network communications are typically more interactive. A
peer does not send data until another peer asks for it using a read command.
A network read typically involves a series of peek named pipes messages
before it begins to read the data. These can be very costly in a slow
network and cause excessive network traffic, which in turn affects other
network clients.
It is also important to clarify if you are talking about local pipes or
network pipes. If the server application is running locally on the computer
running an instance of Microsoft® SQL ServerT 2000, the local Named Pipes
protocol is an option. Local named pipes runs in kernel mode and is
extremely fast.
For TCP/IP Sockets, data transmissions are more streamlined and have less
overhead. Data transmissions can also take advantage of TCP/IP Sockets
performance enhancement mechanisms such as windowing, delayed
acknowledgements, and so on, which can be very beneficial in a slow network.
Depending on the type of applications, such performance differences can be
significant.
TCP/IP Sockets also support a backlog queue, which can provide a limited
smoothing effect compared to named pipes that may lead to pipe busy errors
when you are attempting to connect to SQL Server.
In general, sockets are preferred in a slow LAN, WAN, or dial-up network,
whereas named pipes can be a better choice when network speed is not the
issue, as it offers more functionality, ease of use, and configuration
options.
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:ORNMyEE8DHA.3360@.tk2msftngp13.phx.gbl...
> I have read that Named pipes work faster/better in a LAN environment ? I
> have a question.. so would it make sense if the Web Servers (IIS on
Windows
> 2000) that talk to the database servers on the same LAN communicate via
> Named pipes as opposed to TCPIP . Also same with regards to the business
> tier thats also on the same LAN that talks to the databases that can
> communicate using Named pipes
> Please provide your inputs here . Currently we use TCPIP. Using SQL 2000
>|||Another thing to consider with Named Pipes is that the
user's Windows user accounts must have permission to
establish a NetBEUI connection to the Windows box that
SQL Server is running on. This is not the case when
using TCP/IP Sockets.
Just out of curiosity, where did you read that Named
Pipes was faster/better in a LAN environment? The last
time I experienced Named Pipes to be noticeably faster
was with a 16 bit client.
Matthew Bando
matthew.bando@.CSCTGI(Remove this).com
>--Original Message--
>I have read that Named pipes work faster/better in a LAN
environment ? I
>have a question.. so would it make sense if the Web
Servers (IIS on Windows
>2000) that talk to the database servers on the same LAN
communicate via
>Named pipes as opposed to TCPIP . Also same with regards
to the business
>tier thats also on the same LAN that talks to the
databases that can
>communicate using Named pipes
>Please provide your inputs here . Currently we use
TCPIP. Using SQL 2000
>
>.
>
Named Pipe question
Hi,
I'm wondering when do I need to use the Named Pipes connection in our SQL
Server 2000 and clients environment?
If all our LAN are running on the TCP/IP, do we need to use the Name Pipes?
Thanks for help.
JasonNamed Pipes is used only for LANs. However it does not support routing and
gateways. As it requires more interaction between your server and your
client you'll need a fast network because of the extra burden (especially
when compared to TCP\IP).
If TCP\IP works fine for you, go with it and disable NP to free some
resources and close extra ways for potention intruders.
--
Ekrem Önsoy
"Jason Huang" <JasonHuang8888@.hotmail.com> wrote in message
news:uiQd%23KFIIHA.5400@.TK2MSFTNGP04.phx.gbl...
> Hi,
> I'm wondering when do I need to use the Named Pipes connection in our SQL
> Server 2000 and clients environment?
> If all our LAN are running on the TCP/IP, do we need to use the Name
> Pipes?
> Thanks for help.
>
> Jason
>|||> Named Pipes is used only for LANs. However it does not support
> routing and gateways.
It's true that you don't route named pipes. But it's also the case you don't
directly route any other SQL Server netlib protocols such as TCP/IP which in
this particular context is really meant to refer to sockets instead of TCP at
the transport layer or IP at the network layer. In other words, you don't
care whether you can directly route any of the session layer protocols such
as sockets, named pipes, or RPC as long as they are built on IP that is
routable.
I don't know all the ancient history of SQL Server, but since 7.0 at least
and possibly with 6.5, named pipes for all that matters are built on top of
TCP/IP and can rely on IP for routing at the network layer.
Linchi
"Ekrem Ã?nsoy" wrote:
> Named Pipes is used only for LANs. However it does not support routing and
> gateways. As it requires more interaction between your server and your
> client you'll need a fast network because of the extra burden (especially
> when compared to TCP\IP).
> If TCP\IP works fine for you, go with it and disable NP to free some
> resources and close extra ways for potention intruders.
> --
> Ekrem nsoy
>
> "Jason Huang" <JasonHuang8888@.hotmail.com> wrote in message
> news:uiQd%23KFIIHA.5400@.TK2MSFTNGP04.phx.gbl...
> > Hi,
> >
> > I'm wondering when do I need to use the Named Pipes connection in our SQL
> > Server 2000 and clients environment?
> > If all our LAN are running on the TCP/IP, do we need to use the Name
> > Pipes?
> > Thanks for help.
> >
> >
> > Jason
> >
>|||> I don't know all the ancient history of SQL Server, but since 7.0 at least
> and possibly with 6.5, named pipes for all that matters are built on top of
> TCP/IP and can rely on IP for routing at the network layer.
Here's how I understand it:
There are network protocols, such as:
TCP/IP (has routing functionality of course)
NetBEUI (very limited, if any, routing functionality)
IPX (original protocol in Novell)
A network protocol is of little use if we can't send data back and fort between application over
that network protocol. So, there are APIs:
NETBIOS (originally developed for NetBEUI, but is also supported over IP (requires WINS for name
resolution))
Sockets (not available for NetBEUI AFAIK, only TCP/IP)
Named Pipes (built on top of NETBIOS)
RPC (implemented and available over both NetBEUI and IP)
SPX (as I understand it, the API over IPX)
When MS released "their" SQL Server, they needed a way for the client app to communicate to the
server. They decided to go for Named Pipes and developed what we call "netlib". I.e., the MS
deveopers used the Named Pipes API (which is similar to reading and writing to a file from the
programmers perspective) when developing the Named Pipes netlib.
Over time, new netlibs were developed, where in 2000, this culminated in below list (netlibs using
the API):
Named Pipes
Sockets
RPC
VIA
SPX
There was never a netlib deveoped directly on top of NETBIOS, but indirectly through Named Pipes.
So, back to the original comment:
> but since 7.0 at least
> and possibly with 6.5, named pipes for all that matters are built on top of
> TCP/IP and can rely on IP for routing at the network layer.
Named Pipes uses NETBIOS, which available over IP, and hence is routable. This isn't tied to a
specific version of SQL Server.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:0A9D3D0D-2539-477C-8885-7CF2A55696F0@.microsoft.com...
>> Named Pipes is used only for LANs. However it does not support
>> routing and gateways.
> It's true that you don't route named pipes. But it's also the case you don't
> directly route any other SQL Server netlib protocols such as TCP/IP which in
> this particular context is really meant to refer to sockets instead of TCP at
> the transport layer or IP at the network layer. In other words, you don't
> care whether you can directly route any of the session layer protocols such
> as sockets, named pipes, or RPC as long as they are built on IP that is
> routable.
> I don't know all the ancient history of SQL Server, but since 7.0 at least
> and possibly with 6.5, named pipes for all that matters are built on top of
> TCP/IP and can rely on IP for routing at the network layer.
> Linchi
> "Ekrem Önsoy" wrote:
>> Named Pipes is used only for LANs. However it does not support routing and
>> gateways. As it requires more interaction between your server and your
>> client you'll need a fast network because of the extra burden (especially
>> when compared to TCP\IP).
>> If TCP\IP works fine for you, go with it and disable NP to free some
>> resources and close extra ways for potention intruders.
>> --
>> Ekrem nsoy
>>
>> "Jason Huang" <JasonHuang8888@.hotmail.com> wrote in message
>> news:uiQd%23KFIIHA.5400@.TK2MSFTNGP04.phx.gbl...
>> > Hi,
>> >
>> > I'm wondering when do I need to use the Named Pipes connection in our SQL
>> > Server 2000 and clients environment?
>> > If all our LAN are running on the TCP/IP, do we need to use the Name
>> > Pipes?
>> > Thanks for help.
>> >
>> >
>> > Jason
>> >
I'm wondering when do I need to use the Named Pipes connection in our SQL
Server 2000 and clients environment?
If all our LAN are running on the TCP/IP, do we need to use the Name Pipes?
Thanks for help.
JasonNamed Pipes is used only for LANs. However it does not support routing and
gateways. As it requires more interaction between your server and your
client you'll need a fast network because of the extra burden (especially
when compared to TCP\IP).
If TCP\IP works fine for you, go with it and disable NP to free some
resources and close extra ways for potention intruders.
--
Ekrem Önsoy
"Jason Huang" <JasonHuang8888@.hotmail.com> wrote in message
news:uiQd%23KFIIHA.5400@.TK2MSFTNGP04.phx.gbl...
> Hi,
> I'm wondering when do I need to use the Named Pipes connection in our SQL
> Server 2000 and clients environment?
> If all our LAN are running on the TCP/IP, do we need to use the Name
> Pipes?
> Thanks for help.
>
> Jason
>|||> Named Pipes is used only for LANs. However it does not support
> routing and gateways.
It's true that you don't route named pipes. But it's also the case you don't
directly route any other SQL Server netlib protocols such as TCP/IP which in
this particular context is really meant to refer to sockets instead of TCP at
the transport layer or IP at the network layer. In other words, you don't
care whether you can directly route any of the session layer protocols such
as sockets, named pipes, or RPC as long as they are built on IP that is
routable.
I don't know all the ancient history of SQL Server, but since 7.0 at least
and possibly with 6.5, named pipes for all that matters are built on top of
TCP/IP and can rely on IP for routing at the network layer.
Linchi
"Ekrem Ã?nsoy" wrote:
> Named Pipes is used only for LANs. However it does not support routing and
> gateways. As it requires more interaction between your server and your
> client you'll need a fast network because of the extra burden (especially
> when compared to TCP\IP).
> If TCP\IP works fine for you, go with it and disable NP to free some
> resources and close extra ways for potention intruders.
> --
> Ekrem nsoy
>
> "Jason Huang" <JasonHuang8888@.hotmail.com> wrote in message
> news:uiQd%23KFIIHA.5400@.TK2MSFTNGP04.phx.gbl...
> > Hi,
> >
> > I'm wondering when do I need to use the Named Pipes connection in our SQL
> > Server 2000 and clients environment?
> > If all our LAN are running on the TCP/IP, do we need to use the Name
> > Pipes?
> > Thanks for help.
> >
> >
> > Jason
> >
>|||> I don't know all the ancient history of SQL Server, but since 7.0 at least
> and possibly with 6.5, named pipes for all that matters are built on top of
> TCP/IP and can rely on IP for routing at the network layer.
Here's how I understand it:
There are network protocols, such as:
TCP/IP (has routing functionality of course)
NetBEUI (very limited, if any, routing functionality)
IPX (original protocol in Novell)
A network protocol is of little use if we can't send data back and fort between application over
that network protocol. So, there are APIs:
NETBIOS (originally developed for NetBEUI, but is also supported over IP (requires WINS for name
resolution))
Sockets (not available for NetBEUI AFAIK, only TCP/IP)
Named Pipes (built on top of NETBIOS)
RPC (implemented and available over both NetBEUI and IP)
SPX (as I understand it, the API over IPX)
When MS released "their" SQL Server, they needed a way for the client app to communicate to the
server. They decided to go for Named Pipes and developed what we call "netlib". I.e., the MS
deveopers used the Named Pipes API (which is similar to reading and writing to a file from the
programmers perspective) when developing the Named Pipes netlib.
Over time, new netlibs were developed, where in 2000, this culminated in below list (netlibs using
the API):
Named Pipes
Sockets
RPC
VIA
SPX
There was never a netlib deveoped directly on top of NETBIOS, but indirectly through Named Pipes.
So, back to the original comment:
> but since 7.0 at least
> and possibly with 6.5, named pipes for all that matters are built on top of
> TCP/IP and can rely on IP for routing at the network layer.
Named Pipes uses NETBIOS, which available over IP, and hence is routable. This isn't tied to a
specific version of SQL Server.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:0A9D3D0D-2539-477C-8885-7CF2A55696F0@.microsoft.com...
>> Named Pipes is used only for LANs. However it does not support
>> routing and gateways.
> It's true that you don't route named pipes. But it's also the case you don't
> directly route any other SQL Server netlib protocols such as TCP/IP which in
> this particular context is really meant to refer to sockets instead of TCP at
> the transport layer or IP at the network layer. In other words, you don't
> care whether you can directly route any of the session layer protocols such
> as sockets, named pipes, or RPC as long as they are built on IP that is
> routable.
> I don't know all the ancient history of SQL Server, but since 7.0 at least
> and possibly with 6.5, named pipes for all that matters are built on top of
> TCP/IP and can rely on IP for routing at the network layer.
> Linchi
> "Ekrem Önsoy" wrote:
>> Named Pipes is used only for LANs. However it does not support routing and
>> gateways. As it requires more interaction between your server and your
>> client you'll need a fast network because of the extra burden (especially
>> when compared to TCP\IP).
>> If TCP\IP works fine for you, go with it and disable NP to free some
>> resources and close extra ways for potention intruders.
>> --
>> Ekrem nsoy
>>
>> "Jason Huang" <JasonHuang8888@.hotmail.com> wrote in message
>> news:uiQd%23KFIIHA.5400@.TK2MSFTNGP04.phx.gbl...
>> > Hi,
>> >
>> > I'm wondering when do I need to use the Named Pipes connection in our SQL
>> > Server 2000 and clients environment?
>> > If all our LAN are running on the TCP/IP, do we need to use the Name
>> > Pipes?
>> > Thanks for help.
>> >
>> >
>> > Jason
>> >
Monday, March 26, 2012
Named Pipe and Clustering
Hi,
I need to disable named pipes in a SQL Cluster environment (Windows 2000 and
SQL 2000 latest SP). Here is the scenario:
Our security policy requires me to secure my production SQL Server (Virtual
SQL Cluster name=SQL01) by disabling any access to SQL Server except access
from application server. I implemented this security in UAT (Non clustered )
by creating an IPSEC filter and disabling Named Pipes on SQL Server. In one
IPSEC filter, All IP Traffic to port 1433 is blocked. In another filter,
traffic from application server IP Address is permitted. This configuration
worked fine in UAT.
When I promoted the same IPSEC policy to production (both nodes
active-passive), I noticed that I can't disable Named Pipes in cluster
environment. Is there any work around this?
Can I change default pipe for Named Pipe in order to block SQL connections
coming from default pipe?
Do you have any better suggestion to secure SQL Server?
ThanksThis was an update in sp3 that was not well documented. After installing
sp3, you can't remove Named Pipes on a Cluster. If Named Pipes was
previously removed (prior to sp3) , then it will not add it back.
We experienced numerous customer problems where the server would not come
online, and it was only listening on tcp. Here's the full reference in the
kb.
831127 Named Pipes Support Cannot Be Removed on a Virtual Server That Is
http://support.microsoft.com/?id=831127
My recommendation would be to use ISA server and publish the SQL Server.
This will allow you to only publish the TCP netlib.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
I need to disable named pipes in a SQL Cluster environment (Windows 2000 and
SQL 2000 latest SP). Here is the scenario:
Our security policy requires me to secure my production SQL Server (Virtual
SQL Cluster name=SQL01) by disabling any access to SQL Server except access
from application server. I implemented this security in UAT (Non clustered )
by creating an IPSEC filter and disabling Named Pipes on SQL Server. In one
IPSEC filter, All IP Traffic to port 1433 is blocked. In another filter,
traffic from application server IP Address is permitted. This configuration
worked fine in UAT.
When I promoted the same IPSEC policy to production (both nodes
active-passive), I noticed that I can't disable Named Pipes in cluster
environment. Is there any work around this?
Can I change default pipe for Named Pipe in order to block SQL connections
coming from default pipe?
Do you have any better suggestion to secure SQL Server?
ThanksThis was an update in sp3 that was not well documented. After installing
sp3, you can't remove Named Pipes on a Cluster. If Named Pipes was
previously removed (prior to sp3) , then it will not add it back.
We experienced numerous customer problems where the server would not come
online, and it was only listening on tcp. Here's the full reference in the
kb.
831127 Named Pipes Support Cannot Be Removed on a Virtual Server That Is
http://support.microsoft.com/?id=831127
My recommendation would be to use ISA server and publish the SQL Server.
This will allow you to only publish the TCP netlib.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
Wednesday, March 21, 2012
name of instance
I just setup a new database machine... in my home environment
and want to test replication and subscribion
I am using windows 2003 server and sql 2000 server,
i have create a instance name while installion... but after around 15
days...
the instance name automatic changed to "local".. and then I can not create a
replication anymore because the sql server said that "local" can as a name
of distributor ...
any anyone tell me what i can/should do?
Many Thanks..
Thanks in advanced.Hi
If the instance is called (local) this would imply a default instance and
not a named instance! You can refer to a default instance by the machine name.
John
"beachboy" wrote:
> I just setup a new database machine... in my home environment
> and want to test replication and subscribion
> I am using windows 2003 server and sql 2000 server,
> i have create a instance name while installion... but after around 15
> days...
> the instance name automatic changed to "local".. and then I can not create a
> replication anymore because the sql server said that "local" can as a name
> of distributor ...
> any anyone tell me what i can/should do?
> Many Thanks..
> Thanks in advanced.
>
>
and want to test replication and subscribion
I am using windows 2003 server and sql 2000 server,
i have create a instance name while installion... but after around 15
days...
the instance name automatic changed to "local".. and then I can not create a
replication anymore because the sql server said that "local" can as a name
of distributor ...
any anyone tell me what i can/should do?
Many Thanks..
Thanks in advanced.Hi
If the instance is called (local) this would imply a default instance and
not a named instance! You can refer to a default instance by the machine name.
John
"beachboy" wrote:
> I just setup a new database machine... in my home environment
> and want to test replication and subscribion
> I am using windows 2003 server and sql 2000 server,
> i have create a instance name while installion... but after around 15
> days...
> the instance name automatic changed to "local".. and then I can not create a
> replication anymore because the sql server said that "local" can as a name
> of distributor ...
> any anyone tell me what i can/should do?
> Many Thanks..
> Thanks in advanced.
>
>
Friday, March 9, 2012
MyLittleAdmin Error -2147217900 - Incorrect syntax near ''(''.
Hi,
I'm trying to create various tables on a hosted environment. Unfortunately the hosting company (lets just say 1 + 1 don't = 2) don't support remote connections so I can't access the DB using MS SQL Management Studio. So I have to use a 3rd party tool - MyLittleAdmin.
I'm trying to create various tables on a hosted environment. Unfortunately the hosting company (lets just say 1 + 1 don't = 2) don't support remote connections so I can't access the DB using MS SQL Management Studio. So I have to use a 3rd party tool - MyLittleAdmin.
I can import scripts, and the majority of the time its ok, but I can't create certain tables that uses the generated scripts from Management Studio.
The error I received is:
Error -2147217900
Line 14: Incorrect syntax near '('.
The Script is:
Code Snippet
USE
[dbName]
GO
/****** Object: Table [dbo].[tfs_AreaManager] Script Date: 08/06/2007 14:29:46 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[tfs_AreaManager](
[armId] [bigint] IDENTITY(1,1) NOT NULL,
[armUserId] [uniqueidentifier] NOT NULL,
[armAreaName] [nvarchar](20) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[armRgmId] [bigint] NULL,
[armFName] [nvarchar](30) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[armSName] [nvarchar](30) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[armEmail] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[armPhone] [nvarchar](15) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
CONSTRAINT [PK_tfs_AreaManagers] PRIMARY KEY CLUSTERED
(
[armId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[tfs_AreaManager] WITH CHECK ADD CONSTRAINT [FK_tfs_AreaManager_tfs_RegionManager] FOREIGN KEY([armRgmId])
REFERENCES [dbo].[tfs_RegionManager] ([rgmId])
GO
ALTER TABLE [dbo].[tfs_AreaManager] CHECK CONSTRAINT [FK_tfs_AreaManager_tfs_RegionManager]
I think line 14 refers to the 14th line counting from the 3rd GO instruction (code highlighted in RED).
Can anyone advise me as to what the problem is. I can create the table if I only use the script before the constraint operation. If I create the table, and then just script the constraints after, then they fail too. So I know it is the constraint opertaion that is the problem. Any help would be greatly appreciated!
Seems that you create the scripts with a SQL Server 2005 instance and the target one is a SQL Server 2000< one (or pretends to be in terms of compability level). So either change the compat level (if the target instance is a 2005 server) or create the scripts with compat level of your target database.
Jens K. Suessmeyer
http://www.sqlserver2005.de
|||
Oh that could be it! Do you know how I generate scripts for a SQL Server 2000 target?
Thanks for the help.
|||
If you are using the script generator you can use the "Script for Server Version" > SQL Server 2000
Jens K. Suessmeyer
http://www.sqlserver2005.de
Wednesday, March 7, 2012
my sql server not listed in pull down list of 3rd party tool
hi there,
I am installing a network managing tool in a test environment that relies on
sql database. when opening the pull down list I can see all sql and msde
server from my colleagues but mine.
When introducing it manually with all credentials and domain info and hit
"test logon", it returns: "There was an error testing the windows logon
credentials. windows reports the error as Logon failure: uknown user name or
bad password. Latter are all correct.
- Why can I not see the server in the pull down menu?
- What could be the connection issue?
Dominique
1. It probably uses some flavor of SQLBrowseConnect and not
all servers are guaranteed to be listed due to network
issues, if services are running, protocols, etc. You can
find more information in the following article:
http://www.sqldev.net/misc/ListSQLSvr.htm
2. I'm not sure what tool you are using or what you mean
exactly by introducing it manually, but if windows gives you
an error of unknown user name or bad password, then you
likely have not used the correct user and password. You can
test by logging into the domain with the user name and
password. If it works and the tool doesn't, you should
contact the vendor of the network tool.
-Sue
On Mon, 31 Jan 2005 14:20:47 +0100, "ITspecialist"
<hotspare@.hotmail.com> wrote:
>hi there,
>I am installing a network managing tool in a test environment that relies on
>sql database. when opening the pull down list I can see all sql and msde
>server from my colleagues but mine.
>When introducing it manually with all credentials and domain info and hit
>"test logon", it returns: "There was an error testing the windows logon
>credentials. windows reports the error as Logon failure: uknown user name or
>bad password. Latter are all correct.
>- Why can I not see the server in the pull down menu?
>- What could be the connection issue?
>Dominique
>
I am installing a network managing tool in a test environment that relies on
sql database. when opening the pull down list I can see all sql and msde
server from my colleagues but mine.
When introducing it manually with all credentials and domain info and hit
"test logon", it returns: "There was an error testing the windows logon
credentials. windows reports the error as Logon failure: uknown user name or
bad password. Latter are all correct.
- Why can I not see the server in the pull down menu?
- What could be the connection issue?
Dominique
1. It probably uses some flavor of SQLBrowseConnect and not
all servers are guaranteed to be listed due to network
issues, if services are running, protocols, etc. You can
find more information in the following article:
http://www.sqldev.net/misc/ListSQLSvr.htm
2. I'm not sure what tool you are using or what you mean
exactly by introducing it manually, but if windows gives you
an error of unknown user name or bad password, then you
likely have not used the correct user and password. You can
test by logging into the domain with the user name and
password. If it works and the tool doesn't, you should
contact the vendor of the network tool.
-Sue
On Mon, 31 Jan 2005 14:20:47 +0100, "ITspecialist"
<hotspare@.hotmail.com> wrote:
>hi there,
>I am installing a network managing tool in a test environment that relies on
>sql database. when opening the pull down list I can see all sql and msde
>server from my colleagues but mine.
>When introducing it manually with all credentials and domain info and hit
>"test logon", it returns: "There was an error testing the windows logon
>credentials. windows reports the error as Logon failure: uknown user name or
>bad password. Latter are all correct.
>- Why can I not see the server in the pull down menu?
>- What could be the connection issue?
>Dominique
>
my sql server not listed in pull down list of 3rd party tool
hi there,
I am installing a network managing tool in a test environment that relies on
sql database. when opening the pull down list I can see all sql and msde
server from my colleagues but mine.
When introducing it manually with all credentials and domain info and hit
"test logon", it returns: "There was an error testing the windows logon
credentials. windows reports the error as Logon failure: uknown user name or
bad password. Latter are all correct.
- Why can I not see the server in the pull down menu?
- What could be the connection issue?
Dominique1. It probably uses some flavor of SQLBrowseConnect and not
all servers are guaranteed to be listed due to network
issues, if services are running, protocols, etc. You can
find more information in the following article:
http://www.sqldev.net/misc/ListSQLSvr.htm
2. I'm not sure what tool you are using or what you mean
exactly by introducing it manually, but if windows gives you
an error of unknown user name or bad password, then you
likely have not used the correct user and password. You can
test by logging into the domain with the user name and
password. If it works and the tool doesn't, you should
contact the vendor of the network tool.
-Sue
On Mon, 31 Jan 2005 14:20:47 +0100, "ITspecialist"
<hotspare@.hotmail.com> wrote:
>hi there,
>I am installing a network managing tool in a test environment that relies o
n
>sql database. when opening the pull down list I can see all sql and msde
>server from my colleagues but mine.
>When introducing it manually with all credentials and domain info and hit
>"test logon", it returns: "There was an error testing the windows logon
>credentials. windows reports the error as Logon failure: uknown user name o
r
>bad password. Latter are all correct.
>- Why can I not see the server in the pull down menu?
>- What could be the connection issue?
>Dominique
>
I am installing a network managing tool in a test environment that relies on
sql database. when opening the pull down list I can see all sql and msde
server from my colleagues but mine.
When introducing it manually with all credentials and domain info and hit
"test logon", it returns: "There was an error testing the windows logon
credentials. windows reports the error as Logon failure: uknown user name or
bad password. Latter are all correct.
- Why can I not see the server in the pull down menu?
- What could be the connection issue?
Dominique1. It probably uses some flavor of SQLBrowseConnect and not
all servers are guaranteed to be listed due to network
issues, if services are running, protocols, etc. You can
find more information in the following article:
http://www.sqldev.net/misc/ListSQLSvr.htm
2. I'm not sure what tool you are using or what you mean
exactly by introducing it manually, but if windows gives you
an error of unknown user name or bad password, then you
likely have not used the correct user and password. You can
test by logging into the domain with the user name and
password. If it works and the tool doesn't, you should
contact the vendor of the network tool.
-Sue
On Mon, 31 Jan 2005 14:20:47 +0100, "ITspecialist"
<hotspare@.hotmail.com> wrote:
>hi there,
>I am installing a network managing tool in a test environment that relies o
n
>sql database. when opening the pull down list I can see all sql and msde
>server from my colleagues but mine.
>When introducing it manually with all credentials and domain info and hit
>"test logon", it returns: "There was an error testing the windows logon
>credentials. windows reports the error as Logon failure: uknown user name o
r
>bad password. Latter are all correct.
>- Why can I not see the server in the pull down menu?
>- What could be the connection issue?
>Dominique
>
Subscribe to:
Posts (Atom)