Have a web service on IIS that my client code calls via the System.Runtime.Remoting subsystem. The web service trys to fetch a record from SQL Server Express 2005. Worked perfect with SQL Server 2000.

With SQL Server Express 2005, I get the following:

An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

I've tried everything I can think of to confidure SQL Server 2005 for remote connections.

Anyone ever had a similar problem and fixed it?

Bob

I apologize for cross posting, but got desperate with a n-tier app that didn't have a clear primary forum. Anyway, I have SQL Server Express configured correctly to recieve remote calls. My problem was that I only had my connection string in my remote web.config file; I needed the local and remote connection strings in my client app.config file as well. Once there, works like its 'sposed tooo.

Bob

Should the client app be connecting to the database directly? Or should this be happening thru the remote interface?

-Peter

Hi Peter,

I have it set up so that the code determines at runtime whether remoting needs to be configured or not based on the app.config file setting. The setting determines the location of a DataPortal object.


<appSettings>
  <add key="PortalServer" value="http://localhost/DataPortal/DataPortal.rem" />


     </appSettings>


If code finds the "PortalServer" key, remote connection.
If code finds the "TetsDB" key, direct (local) connection.

Finally got it working, though.

Best,

Bob

So you've fixed it? I'd be interested to know what the problem turned out to be.

-------------------------

Whatever you can do or dream you can, begin it. Boldness has genius, power and magic in it. Begin it now.
-Johann von Goethe

When Two Hearts Race... Both Win.
-Dove Chocolate Wrapper

Chroniclemaster1, Founder of www.EarthChronicle.com
A Growing History of our Planet, by our Planet, for our Planet.

Turns out the operative word in the error message:

"this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections"

is 'may'.

The failure may also be caused by me writing code that forgets to initialize my connection string variable.

I needed my connection string in both my app.config and web.config files. Only had it in web.config. Just the way I have things set up. Using a DataPortal component that decides whether to connect locally or remotely at run time based on what the app.config file has to say.

I also enabled remote connections through the SQL Server Surface Area Configuration tool, and enabled TCP/IP in the SQL Server Configuration manager.

Best,

Bob

Here's an interesting Martin Fowler article I came across recently. It's a bit old, but still quite applicable. It discusses use of distributed objects. Very interesting read for anyone using remoting or the like to distribute your application.

http://www.ddj.com/architect/184414966

-Peter

Thanks Peter,

Everything I know about distributed objects I learned from Rockford Lhotka. I'm pretty fascinated by his Component-based, Scalable Logical Architecture (CSLA). If you havn't bumped into it, definitely check it out:

http://www.lhotka.net/cslanet

Most of my recent posts have involved trying to implement CSLA with just the Express versions of VS (C# Express and VWD), SQL Server Express, and IIS 7 on Vista.

The CSLA Framework implements complete and awesome components that support remoting/serialization, remote and local data portal access, data-binding, role-based security, business rule validation, n-level undo for business objects, batch queing, testing, everything you need for distributed programming. The framework can also be referenced by either Web or Windows interfaces, or Web Services. All ya' gotta do is write your own business objects that inherit base business classes in the framework, and write stored procedures. And design an interface, of course. Source code is available for download.

I was a little nervous that the Express Editions wouldn't support all the functionality, but amazingly they do. Pretty cool free development tools. Good for MS.

Best,

Bob

CSLA also supports distributed transactions through Enterprise Services. That was the final piece I got smoothed out tonight. Forgot I had to strong-name my assemblies. Alls well.

Bob

One caveat that you need to be aware off: CSLA can't use the built-in web server that comes with Visual Studio. You probably know that as you refer to IIS, but I wanted to mention it anyway.

I know Lhotka mentions it in his book, but the first time I was stubborn and tried it anyway... ;)

Imar
---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of ASP.NET 2.0 Instant Results and Beginning Dreamweaver MX / MX 2004
Want to be my colleague? Then check out this post.