Attach network database Sql Server Express

I am trying to attach a network database to my sql server express

After some reading I "Enabled" tcp/ip, named pipes, and shared memory in sql server confiuration manager.

But when I go to "Attach Database" in Sql Express managemnent studio. It does not show the network drives much less allow me to attach anything on a network drive.

What am I missing here?

If I install sql server on the network machine will my local Sql express recognize it?

Database files on network shares are not supported.

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de|||You can also see http://support.microsoft.com/kb/304261.

Asymmetric communication from ms-sql-m protocol from an SQL Cluster

We are installing an application that requires access to the ms-sql-m
protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
we are using is part of an N+1 cluster. The issue is that when we try
to communicate to the node instance xxx.xxx.123.226 recieve the
ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
an asymmetric IP communication and the response appears to be dropped
by the request as one might expect. This causing our installation to
fail.
Has anyone run into this issue before, no of a common misconfiguration
in clustering services that leads to this, or aware of any documented
bug?
Thanks in advance for you posts.
Actually, this is typical of MS cluster applications. The response comes
back from the underlying NIC address, not the cluster virtual address. It
ain't a bug, it's a feature. Or at least it has always operated this way
and could therefore be considered a standard.
Sorry this isn't the answer you were looking for, but it is the way the
system actually works.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
<ddnash@.gmail.com> wrote in message
news:1165524543.657106.172130@.79g2000cws.googlegro ups.com...
> We are installing an application that requires access to the ms-sql-m
> protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
> we are using is part of an N+1 cluster. The issue is that when we try
> to communicate to the node instance xxx.xxx.123.226 recieve the
> ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
> an asymmetric IP communication and the response appears to be dropped
> by the request as one might expect. This causing our installation to
> fail.
> Has anyone run into this issue before, no of a common misconfiguration
> in clustering services that leads to this, or aware of any documented
> bug?
>
> Thanks in advance for you posts.
>
|||I found the following article that does acknowledge the issue and
states that MS has chosen not to address it at this point, but there
are a couple of workarounds.
http://blogs.msdn.com/sql_protocols/archive/2006/02/27/539706.aspx
Thanks for the post.
Geoff N. Hiten wrote:[vbcol=seagreen]
> Actually, this is typical of MS cluster applications. The response comes
> back from the underlying NIC address, not the cluster virtual address. It
> ain't a bug, it's a feature. Or at least it has always operated this way
> and could therefore be considered a standard.
> Sorry this isn't the answer you were looking for, but it is the way the
> system actually works.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> <ddnash@.gmail.com> wrote in message
> news:1165524543.657106.172130@.79g2000cws.googlegro ups.com...
sql

Asymmetric communication from ms-sql-m protocol from an SQL Cluster

We are installing an application that requires access to the ms-sql-m
protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
we are using is part of an N+1 cluster. The issue is that when we try
to communicate to the node instance xxx.xxx.123.226 recieve the
ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
an asymmetric IP communication and the response appears to be dropped
by the request as one might expect. This causing our installation to
fail.
Has anyone run into this issue before, no of a common misconfiguration
in clustering services that leads to this, or aware of any documented
bug?
Thanks in advance for you posts.Actually, this is typical of MS cluster applications. The response comes
back from the underlying NIC address, not the cluster virtual address. It
ain't a bug, it's a feature. :) Or at least it has always operated this way
and could therefore be considered a standard.
Sorry this isn't the answer you were looking for, but it is the way the
system actually works.
--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
<ddnash@.gmail.com> wrote in message
news:1165524543.657106.172130@.79g2000cws.googlegroups.com...
> We are installing an application that requires access to the ms-sql-m
> protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
> we are using is part of an N+1 cluster. The issue is that when we try
> to communicate to the node instance xxx.xxx.123.226 recieve the
> ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
> an asymmetric IP communication and the response appears to be dropped
> by the request as one might expect. This causing our installation to
> fail.
> Has anyone run into this issue before, no of a common misconfiguration
> in clustering services that leads to this, or aware of any documented
> bug?
>
> Thanks in advance for you posts.
>|||I found the following article that does acknowledge the issue and
states that MS has chosen not to address it at this point, but there
are a couple of workarounds.
http://blogs.msdn.com/sql_protocols/archive/2006/02/27/539706.aspx
Thanks for the post.
Geoff N. Hiten wrote:
> Actually, this is typical of MS cluster applications. The response comes
> back from the underlying NIC address, not the cluster virtual address. It
> ain't a bug, it's a feature. :) Or at least it has always operated this way
> and could therefore be considered a standard.
> Sorry this isn't the answer you were looking for, but it is the way the
> system actually works.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> <ddnash@.gmail.com> wrote in message
> news:1165524543.657106.172130@.79g2000cws.googlegroups.com...
> > We are installing an application that requires access to the ms-sql-m
> > protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
> >
> > we are using is part of an N+1 cluster. The issue is that when we try
> > to communicate to the node instance xxx.xxx.123.226 recieve the
> > ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
> > an asymmetric IP communication and the response appears to be dropped
> > by the request as one might expect. This causing our installation to
> > fail.
> >
> > Has anyone run into this issue before, no of a common misconfiguration
> > in clustering services that leads to this, or aware of any documented
> > bug?
> >
> >
> > Thanks in advance for you posts.
> >

Asymmetric communication from ms-sql-m protocol from an SQL Cluster

We are installing an application that requires access to the ms-sql-m
protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
we are using is part of an N+1 cluster. The issue is that when we try
to communicate to the node instance xxx.xxx.123.226 recieve the
ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
an asymmetric IP communication and the response appears to be dropped
by the request as one might expect. This causing our installation to
fail.
Has anyone run into this issue before, no of a common misconfiguration
in clustering services that leads to this, or aware of any documented
bug?
Thanks in advance for you posts.Actually, this is typical of MS cluster applications. The response comes
back from the underlying NIC address, not the cluster virtual address. It
ain't a bug, it's a feature. Or at least it has always operated this way
and could therefore be considered a standard.
Sorry this isn't the answer you were looking for, but it is the way the
system actually works.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
<ddnash@.gmail.com> wrote in message
news:1165524543.657106.172130@.79g2000cws.googlegroups.com...
> We are installing an application that requires access to the ms-sql-m
> protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
> we are using is part of an N+1 cluster. The issue is that when we try
> to communicate to the node instance xxx.xxx.123.226 recieve the
> ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
> an asymmetric IP communication and the response appears to be dropped
> by the request as one might expect. This causing our installation to
> fail.
> Has anyone run into this issue before, no of a common misconfiguration
> in clustering services that leads to this, or aware of any documented
> bug?
>
> Thanks in advance for you posts.
>|||I found the following article that does acknowledge the issue and
states that MS has chosen not to address it at this point, but there
are a couple of workarounds.
http://blogs.msdn.com/sql_protocols.../27/539706.aspx
Thanks for the post.
Geoff N. Hiten wrote:[vbcol=seagreen]
> Actually, this is typical of MS cluster applications. The response comes
> back from the underlying NIC address, not the cluster virtual address. It
> ain't a bug, it's a feature. Or at least it has always operated this w
ay
> and could therefore be considered a standard.
> Sorry this isn't the answer you were looking for, but it is the way the
> system actually works.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> <ddnash@.gmail.com> wrote in message
> news:1165524543.657106.172130@.79g2000cws.googlegroups.com...

ASP/ODBC/Win2k - TCP Connections

Is it normal to see a new TCP connection for every SQL statement
executed [via ADODB.Recordset.Open] when connection pooling is
switched on?
When my ASP application is running there seems to be 1 constant
connection open, and 3 or 4 separate and continually opening/closing
connections. On examining the packets, it seems that each SQL gets
its own connection to the server.
Thanks
()z
If you are using ODBC this is not uncommon. ODBC determines when it needs
to spawn a new connection and does so. This can occur if a connection has
not finished processing all records and another request is sent. A new
connection has to be spawned to service this request.
Rand
This posting is provided "as is" with no warranties and confers no rights.
|||Thanks Rand
I'll not worry about them in that case.
rboyd@.onlinemicrosoft.com (Rand Boyd [MSFT]) wrote in message news:<L71m5yREEHA.3244@.cpmsftngxa06.phx.gbl>...
> If you are using ODBC this is not uncommon. ODBC determines when it needs
> to spawn a new connection and does so. This can occur if a connection has
> not finished processing all records and another request is sent. A new
> connection has to be spawned to service this request.
> Rand
> This posting is provided "as is" with no warranties and confers no rights.