Chrome apparently became the 2nd most popular browser already. A laggard as usual, I decided to finally give it a shot. It happened that my car tag renewal was due, so I went to our friendly DMV web site to renew it. At the end of the workflow, there is a screen for for printing the confirmation of payments. Here it is:

It couldn’t do it. I guess so much for my Chrome experience.
I know, I know, Firefox 2.0 is so yesterday. The latest is 8.x already. I happen to have a laptop running Windows XP SP1 with Firefox 2.0 for testing, and I sidetracked myself a bit surfing around for a few minutes on my frequently visited SNS sites:
- Google Plus
From the screenshots above, LinkedIn easily tops the most friendly SNS site for Firefox 2.0. No wonder it is my favorite.
It is pretty exciting to see it announced to the general public. It greatly simplifies the ways user interact with data. A teaser video is available online for a sneak preview of its capabilities.
SQL Server Reporting Services 2008 R2 added support for SQL Azure data source. It is nice to have as this makes it easier to put one foot of your report into the cloud. Sometimes, report server throws this mysterious (and much dreaded) error:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server)
It usually happens like this: report works in Report Builder, report works in BIDS, SQL Server Management Studio has no trouble whatsoever connecting to the data source, but, once the report is deployed to the server and when user tries to run it, out of the blue, this error jumps out. As the message suggests, it is a network issue. Usually, the SQL Azure data source has to be access via a proxy (e.g., Reporting Services get to it through ISA client installed on the report server). You can configure the Report Server service to run under any of these account types:
- Least-privileged Windows user account
- NetworkService
- LocalSystem
- LocalService
And the service account is the one being used to get across the proxy and reach out to the SQL Azure server sitting in the cloud. If your reporting server is running behind the firewall, more often than not, only a “Least-privileged Windows user account” has permission on the proxy server to sneak out. Thus, if Report Server is using any of the other three as the service account, chances are good that it won’t be able to get hold of a connection to SQL Azure server. I hope the workaround is obvious to you at this point now, yes, set the service account to a least-privileged Windows user account which happens to have permission on the proxy server.
- http://technet.microsoft.com/en-us/library/ff519560%28SQL.105%29.aspx
- http://msdn.microsoft.com/en-us/library/ms160340.aspx
Recent Comments