Canot Telnet into port 1433 affter intalling SQL Server !

I'm working on a completely virgin install of SQL Server 2k in Windows 2003.
Just after install I check that the TCP/IP protocol is enabled under the
server properties and then I try to Telnet into port 1433. On this one
particular box I get back the following:

C:\>telnet localhost 1433
Connecting to localhost...Could not open connection to the host, on port
1433: Connect failed.

For comparison I tested telnet on a couple other machines and I get back a
blank window ready for my commands, as I'd expect.

I've checked the firewall settings and other IP Filtering settings to see if
any of those were blocking traffic to 1433... nothing. I've triple checked
the SQL Server settings for any "problems" and nothing jumps out at me.Have you configured the server to listen to port 1433? Is it set to Dynamic?|||Try installing SQLServer 2000 SP3 or 3a if you have not already.|||

add to your conecction string: namedPipe=true

i hope this solve your problem

Canot Telnet into port 1433 affter intalling SQL Server !

I'm working on a completely virgin install of SQL Server 2k in Windows 2003.
Just after install I check that the TCP/IP protocol is enabled under the
server properties and then I try to Telnet into port 1433. On this one
particular box I get back the following:

C:\>telnet localhost 1433
Connecting to localhost...Could not open connection to the host, on port
1433: Connect failed.

For comparison I tested telnet on a couple other machines and I get back a
blank window ready for my commands, as I'd expect.

I've checked the firewall settings and other IP Filtering settings to see if
any of those were blocking traffic to 1433... nothing. I've triple checked
the SQL Server settings for any "problems" and nothing jumps out at me.Have you configured the server to listen to port 1433? Is it set to Dynamic?|||Try installing SQLServer 2000 SP3 or 3a if you have not already.|||

add to your conecction string: namedPipe=true

i hope this solve your problem

Canot Telnet into port 1433 affter intalling SQL Server !

I'm working on a completely virgin install of SQL Server 2k in Windows 2003.
Just after install I check that the TCP/IP protocol is enabled under the
server properties and then I try to Telnet into port 1433. On this one
particular box I get back the following:

C:\>telnet localhost 1433
Connecting to localhost...Could not open connection to the host, on port
1433: Connect failed.

For comparison I tested telnet on a couple other machines and I get back a
blank window ready for my commands, as I'd expect.

I've checked the firewall settings and other IP Filtering settings to see if
any of those were blocking traffic to 1433... nothing. I've triple checked
the SQL Server settings for any "problems" and nothing jumps out at me.

Have you configured the server to listen to port 1433? Is it set to Dynamic?|||Try installing SQLServer 2000 SP3 or 3a if you have not already.|||

add to your conecction string: namedPipe=true

i hope this solve your problem

Cannot sync when Auto Identity Ranges Enabled?

I have been pulling my hair out with this for some time now:
I have a small db which I need to merge replicate with a number of PocketPC
devices. NT Authentication is used.
If I do not enable the automatic identity range option, the PocketPC clients
can connect without error. However, if I enable this (which I need to), the
PocketPC user gets a host of errors:
1. (Code 80004005) A call to SQL Server Reconciler failed.
2. (Code 80045007) The merge process could not retrieve article information
for publication 'Survey'
3. (Code 0) {call sp_MShelpmergearticles(?,8000000,?)}
4. (Code 4833) Could not connect to server 'SERVER1' because 'SQLAdmin' is
not defined as a remote login at the server.
SQLAdmin is our Service startup account. It is a member of the Administrator
group.
The user account being used to connect is a standard domain user account.
If I add the user to the Administrators group the process succeeds
everytime. I have checked permissions on the SQLCE folder, and snapshot
folders and AFAIK they are correct (i.e. the user has write permission).
It looks like a permission problem, but I dont know where. It seems the only
solution to this is to add the user to the Administrators group (totally
unacceptable!).
Any suggestions because I am at a complete loss?
Cheers,
James Goodman
Did you re-run your merge agent? I've had no problem using a domain user
account, particularly if set up for anonymous subscribers. Also, you should
be getting a 280xx error number back from the errors collection in the .Net
code. The MSDN site has a list that precisely defines what each of those
errors mean.
"James Goodman" <jamesATnorton-associates.co.ukREMOVE> wrote in message
news:ufn1ZWObFHA.1404@.TK2MSFTNGP09.phx.gbl...
>I have been pulling my hair out with this for some time now:
> I have a small db which I need to merge replicate with a number of
> PocketPC devices. NT Authentication is used.
> If I do not enable the automatic identity range option, the PocketPC
> clients can connect without error. However, if I enable this (which I need
> to), the PocketPC user gets a host of errors:
> 1. (Code 80004005) A call to SQL Server Reconciler failed.
> 2. (Code 80045007) The merge process could not retrieve article
> information for publication 'Survey'
> 3. (Code 0) {call sp_MShelpmergearticles(?,8000000,?)}
> 4. (Code 4833) Could not connect to server 'SERVER1' because 'SQLAdmin' is
> not defined as a remote login at the server.
> SQLAdmin is our Service startup account. It is a member of the
> Administrator group.
> The user account being used to connect is a standard domain user account.
>
> If I add the user to the Administrators group the process succeeds
> everytime. I have checked permissions on the SQLCE folder, and snapshot
> folders and AFAIK they are correct (i.e. the user has write permission).
> It looks like a permission problem, but I dont know where. It seems the
> only solution to this is to add the user to the Administrators group
> (totally unacceptable!).
>
> Any suggestions because I am at a complete loss?
> --
> Cheers,
> James Goodman
>