August 22, 2010 at 1:14 pm
Hi,
I am trying to deploy the AW SSAS 2008 database and encountered the error below:
Error 1 OLE DB error: OLE DB or ODBC error: Login timeout expired; HYT00; A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.; 08001; Named Pipes Provider: Could not open a connection to SQL Server [5]. ; 08001. 0 0.
My instance of MSSQL is a named instance and a stand-alone server (remote). I have ports 1433 open in windows firewall, remote connections enabled on the server and TCP/IP is also enabled. Also I can connect to the SQL named instance from on the SSAS box using Management Studio. Any help is appreciated.
Thanks
MCTS: BI 2008, MCITP: BI 2008
Stay Thirsty My Friends
August 22, 2010 at 8:08 pm
Since it's named instance can you make sure whether Service broker service is enabled for that instance?
Make sure the credentials used is properly set.
Regards..Vidhya Sagar
SQL-Articles
August 22, 2010 at 11:35 pm
Please check SQL Server Browser service... I think it is not running and stopping you from connecting named instance.
[font="Verdana"]--www.sqlvillage.com[/size][/font]
August 23, 2010 at 7:55 am
You may want to try connecting by IP:Port? Could be a DNS issue?
August 24, 2010 at 7:00 am
Twinsoft SME (8/23/2010)
You may want to try connecting by IP:Port? Could be a DNS issue?
I checked and SQL Browser is started. About DNS issue I am not sure that is the problem. I successfully deployed the SSAS 2005 DB on the same SSAS box which points to the default MSSQL instance on the DB box I am having the issue with now.
MCTS: BI 2008, MCITP: BI 2008
Stay Thirsty My Friends
August 24, 2010 at 8:29 am
The error is indicating it is using Named Pipes so be sure that protocol is enabled in Configuration Manager. You also mention connecting via Management Studio, but if you are running it locally on the same machine, it will be using the Shared Memory protocol. Since this is a named instance, it will probably not be using port 1433 as the default instance will most likely be using that port (which is where the SQL Browser Service comes into play) so in order to get the port that the instance is listening on, you can check the SQL Log (EXEC Master.dbo.xp_readerrorlog) and look for the entry indicating the port and make sure you can connect to that port from the applicable machine (I would recommend a simple telnet session) or you can specify the port in Configuration Manager under the TCP/IP Protocol-> IP Addresses section.
August 24, 2010 at 9:36 am
DavidZahner (8/24/2010)
The error is indicating it is using Named Pipes so be sure that protocol is enabled in Configuration Manager. You also mention connecting via Management Studio, but if you are running it locally on the same machine, it will be using the Shared Memory protocol. Since this is a named instance, it will probably not be using port 1433 as the default instance will most likely be using that port (which is where the SQL Browser Service comes into play) so in order to get the port that the instance is listening on, you can check the SQL Log (EXEC Master.dbo.xp_readerrorlog) and look for the entry indicating the port and make sure you can connect to that port from the applicable machine (I would recommend a simple telnet session) or you can specify the port in Configuration Manager under the TCP/IP Protocol-> IP Addresses section.
David, thanks for your input but I still have the same problem.
Gentlemen, let me apologize because I left out some helpful information about my setup. The named instance database server is MSSQL 2008 x64 running on a Windows 2008 R2 server. As stated above I have TCP/IP enabled, SQL Browser is running, and 1433 opened in Windows Firewall. Also the App server connects to the default instance without any issues and the named instance is configured exactly as the default instance.
I came across a post (although not conclusive) this morning that suggests there is a know bug connecting to SQL 2005/2008 named instances installed on Windows Vista or Windows Server 2008. I am currently digging around Microsoft KB's to see if I come across something.
Thanks,
MCTS: BI 2008, MCITP: BI 2008
Stay Thirsty My Friends
August 27, 2010 at 12:01 pm
a
MCTS: BI 2008, MCITP: BI 2008
Stay Thirsty My Friends
August 27, 2010 at 12:03 pm
MostInterestingMan (8/24/2010)
DavidZahner (8/24/2010)
The error is indicating it is using Named Pipes so be sure that protocol is enabled in Configuration Manager. You also mention connecting via Management Studio, but if you are running it locally on the same machine, it will be using the Shared Memory protocol. Since this is a named instance, it will probably not be using port 1433 as the default instance will most likely be using that port (which is where the SQL Browser Service comes into play) so in order to get the port that the instance is listening on, you can check the SQL Log (EXEC Master.dbo.xp_readerrorlog) and look for the entry indicating the port and make sure you can connect to that port from the applicable machine (I would recommend a simple telnet session) or you can specify the port in Configuration Manager under the TCP/IP Protocol-> IP Addresses section.David, thanks for your input but I still have the same problem.
Gentlemen, let me apologize because I left out some helpful information about my setup. The named instance database server is MSSQL 2008 x64 running on a Windows 2008 R2 server. As stated above I have TCP/IP enabled, SQL Browser is running, and 1433 opened in Windows Firewall. Also the App server connects to the default instance without any issues and the named instance is configured exactly as the default instance.
I came across a post (although not conclusive) this morning that suggests there is a know bug connecting to SQL 2005/2008 named instances installed on Windows Vista or Windows Server 2008. I am currently digging around Microsoft KB's to see if I come across something.
Thanks,
...still no luck on this. I'm still getting the same error. SP1 listed a fix for this issue but I applied the SP and it still doesnt work.
MCTS: BI 2008, MCITP: BI 2008
Stay Thirsty My Friends
November 4, 2011 at 1:26 pm
Wandrag (6/14/2011)
I know that this is an old post... But I have the same issue!I have server A - which is a SQL2008 instance with SP1 installed. I can connect to this server using management studio (from remote servers) and I can run scheduled SSIS jobs against it (from a SQL 2008 R2 - Server B - instance with CU4 installed).
Recently I we've installed Server C. (SQL 2008 R2 RTM - no CU's yet - will do that tonight).
If I log-in remotely to server C, I can connect to server A (using SSIS & management studio).
BUT as soon as I schedule the Job on server C it fails with the same issue described above!
The same job running on Server C, can connect to Server B. (Both servers have SQL2008 R2 installed).
So it's just connect from C to A...
I've checked:
1. SQL browser is running on both servers
2. I've even turned of the firewall. (for now)
3. The credentials that I'm using do have access to ALL the servers.
Is there anything else that I can check?
I have this same issue! I've done all the recommended things and I still can't seem to connect to my remote SQL Server Express. Any advice would be great! I haven't been able to find a unique solution to this anywhere else.
November 7, 2011 at 7:35 am
Wandrag (11/6/2011)
jessamae90 (11/4/2011)
Wandrag (6/14/2011)
I know that this is an old post... But I have the same issue!I have server A - which is a SQL2008 instance with SP1 installed. I can connect to this server using management studio (from remote servers) and I can run scheduled SSIS jobs against it (from a SQL 2008 R2 - Server B - instance with CU4 installed).
Recently I we've installed Server C. (SQL 2008 R2 RTM - no CU's yet - will do that tonight).
If I log-in remotely to server C, I can connect to server A (using SSIS & management studio).
BUT as soon as I schedule the Job on server C it fails with the same issue described above!
The same job running on Server C, can connect to Server B. (Both servers have SQL2008 R2 installed).
So it's just connect from C to A...
I've checked:
1. SQL browser is running on both servers
2. I've even turned of the firewall. (for now)
3. The credentials that I'm using do have access to ALL the servers.
Is there anything else that I can check?
I have this same issue! I've done all the recommended things and I still can't seem to connect to my remote SQL Server Express. Any advice would be great! I haven't been able to find a unique solution to this anywhere else.
Can't really remember what we've done to get this perticular issue sorted.
But I THINK we've installed all the servers with the latest SP's and CUs...
And that worked? I've narrowed my issue down to the connection string. I can't configure it so it will connect to the remote SQL Server Express. It wants to use SQL Server Express on the machine that I'm on.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply