Fresh 64-bit SQL Server install will not field connections from 32-bit processes
-
I am assisting a friend on this one and am completely stumped so thought I would post here in case someone else had the same or a similar issue. All suggestions are welcome!
Sequence of events:
1. Presented bare-metal machine with fresh install of Server 2003 R2 Standard Edition x64 + SP2.
2. Installed SQL Server 2008 R2 x64 Standard Edition.
Post-SQL Server install we can:
1. Connect to the DB engine using 64-bit sqlcmd.exe.
2. Create a 64-bit DSN using the ODBC data sources applet.
We cannot:
1. Connect to the DB engine using SSMS (32-bit).
2. Create a 32-bit DSN using the 32-bit ODBC data sources applet.
For both 32-bit methods:
- When attempting to connect via TCP using explicit port number or tcp: prefix we receive a "forcibly closed by remote host" error.
- When attempting to connect via Shared Memory using server name . or Named Pipes we receive a "No process is on the other end of the pipe." error.
portqry.exe shows SQL Server is listening on port 1433. tcpview shows what we expect as well.
Server restarts, SQL Server service restarts and complete product un/re-installs have all been done...multiple times...in an attempt to resolve the issue.
I have scoured the net for a resolution and have found no information that specifically fits the scenario.
Has anyone run into this type of issue?
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato -
I would check the client protocols for both 64bit and 32bit. From what I've seen the protocols are enabled separately.
-
Thank you for all your responses. We tried the backward cmopat tools, and check the client protocol order. We also tried forcing the protocol to test tcp, named pipes and shared memory explicitly, all to no avail. The puzzling thing is that we can connect usnig 64-bit drivers, however not 32-bit drivers.
The consensus here is that the environment itself, SQL Server 2008 R2 x64 Standard Edition on Server 2003 R2 Standard Edition x64 + SP2, is part of the problem. As a result we have decided to move to Server 2008 R2 x64 Standard Edition.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato -
Were the Windows Server & SQL Server built without any issues ?
Did you find any errors in the error logs ?
Thank You,
Best Regards,
SQLBuddy
-
sqlbuddy123 (9/11/2011)
Were the Windows Server & SQL Server built without any issues ?Yes, they installed without issue. Note that 64-bit connectivity worked fine.
Did you find any errors in the error logs ?
Unfortunately no, nothing interesting in the Windows Event or SQL Server Error logs.
We have since moved on to Server 2008 R2 x64 and SQL Server 2008 R2 x64 is working as expected for both 32-bit and 64-bit clients.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato -
After all the efforts that you have made, I would recommend to contact MS customer support to resolve this. That would save you lot of time and effort.
Thank You,
Best Regards,
SQLBuddy
-
sqlbuddy123 (9/12/2011)
After all the efforts that you have made, I would recommend to contact MS customer support to resolve this. That would save you lot of time and effort.Thank You,
Best Regards,
SQLBuddy
If time allowed, or circumstances compelled me to work with Microsoft on this I would...however we have moved to a config that is working. The best I can hope for is that someone else having the same issue will find this thread and learn of viable option. Thanks for your responses!
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply