p2p.wrox.com Forums

p2p.wrox.com Forums (http://p2p.wrox.com/index.php)
-   C# 2005 (http://p2p.wrox.com/forumdisplay.php?f=138)
-   -   Remoting and SQL Server 2005 Express (http://p2p.wrox.com/showthread.php?t=64751)

Bob Bedell December 21st, 2007 07:54 AM

Remoting and SQL Server 2005 Express
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 Bedell December 21st, 2007 10:31 AM

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.


planoie December 21st, 2007 12:02 PM

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


Bob Bedell December 21st, 2007 05:02 PM

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.

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


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

Finally got it working, though.



chroniclemaster1 December 22nd, 2007 08:49 PM

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.

Bob Bedell December 23rd, 2007 01:27 AM

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.



planoie December 23rd, 2007 10:23 AM

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.



Bob Bedell December 24th, 2007 03:03 AM

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:


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.



Bob Bedell December 24th, 2007 03:15 AM

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.


Imar December 24th, 2007 04:22 AM

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 Spaanjaars
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.

Bob Bedell December 24th, 2007 04:52 AM

Imar! I was just thinking about you! Hit a glitch of the 'way over my head' variety. But I should probably start a new thread for it. So it'll be on this forum called "Wrong Principal Object." Its CSLA related. Sure'ld appraciate any thoughts.


Bob Bedell January 2nd, 2008 05:40 PM

Hi Peter,

I had a chance to read the Fowler article and just have a couple of comments I’d like to share. Frameworks like CSLA built over the .NET framework provide several possible solutions to a few of the primary object design issues Fowler addresses.

His essential objection to the design of the types of distributed objects he discusses seems to be the:

"…essential point that any object that may be used remotely should have a coarse-grained interface, while every object that isn’t used remotely should have a fine-grained interface."

"If you base your distribution strategy on classes, you’ll end up with a system that does a lot of remote calls and thus needs awkward, coarse-grained interfaces."

Not so when you implement serializable, CSLA style mobile objects. When you do, you end up with a very different picture. You end up with:

- a distribution strategy based on classes and

- mobile objects that fully encapsulate all their business logic and data access logic, and can be passed by value (via serialization) to a remote process, and do their work in that process

- which limits remote calls

- to the four standard CRUD methods implemented in an elegantly designed, course-grained data portal router object anchored (MarshalByRefObject) to either a local or application server process (as determined by a configuration file setting).

That’s a mouth full!

This logical architecture can support any physical architecture you like. Hope I can clarify it a little.

The fine-grained, “normally” designed business objects are used remotely via serialization. If a client wants to, say, update a mobile business object it is working with, and the course-grained data portal object is anchored in a remote process, when the client requests the update by calling the data portal Update method, the edited mobile object is serialized and passed by value to that process. The remote process now has a copy of the edited business object it can work with locally, calling properties and methods (like an Update method) of the “smart” business object with no performance overhead. The anchored object instructs the mobile business object to update itself by calling the business object’s Update method (all data access code is encapsulated in the business object). The updated object is then serialized and returned - again by value - to the client. The client now uses the new copy of the updated mobile object.

The only performance hit was in copying the object across the network - using binary transfer which is 30% faster than transferring, say, a DataSet. Doing this of course requires that both machines have the .NET assembly containing the objects code installed, which can be accomplished by a variety of deployment strategies, including .NET deployment strategies.

Fowler states that a “…fine-grained interface doesn’t work well when it’s remote.” This is true only when the fine-grained interface is called from another process. The situation changes completely when the interface is transferred to the remote process, and does its work in that process, which is what .NET technologies enable. A course-grained, anchored interface running in a process with access to the database server still exists (the data portal) for minimizing calls from the client, but now the anchored object and the mobile object run in the same process, and the anchored object can invoke the data access methods encapsulated by the mobile object.

Another problem Fowler mentions that is overcome by .NET serialization is:

“You usually can’t send the domain object itself, because it’s tied in a web of fine-grained local inter-object references.”

When a .NET object is marked as [Serializable()] it and any other object referenced by it is serialized into the byte stream that gets transferred to the remote process. Problem solved (except for certain issues surrounding event handlers which are easily resolved).

The whole remote facade and data transfer object issue is also resolved, because a DOT is no longer required. A copy of the smart business object itself (actually its serialized state data) is sent to the remote process.

Thanks again for the article reference. I hope some of this is intelligible. I'm just thinking through CSLA and distributed programming issues a lot recently, and writing helps a great deal.



Bob Bedell January 2nd, 2008 06:23 PM

Then again, Fowler's remarks apply to CSLA and .NET to a degree, as well. The anchored object in the remote process is still a course-grained interface required by the system, and is really the only object that is called remotely by the client. And, yes, I suppose it is a little awkward in certain respects. And the fine-grained interfaces of the business objects aren't "used" remotely, in the sense of being called by the client. Technically, they are "used" locally by the anchored object, and in a process that is remote only relative to the client process. So Fowler is perfectly correct when he says that a "…fine-grained interface doesn’t work well when it’s remote", if this is taken to mean: doesn’t work well when its called directly by the client, which is, I think, how it should be taken.

What .NET introduces is the concept of designing business objects with "normal", fine-grained interfaces that can do there work in a remote process without the client having to know about them "by reference", with all the performance overhead and network latency that arrangement would entail. Or something along those lines.


Bob Bedell January 2nd, 2008 10:55 PM

Last thought and I'll give it a rest.

In the final analysis, I'd have to say the three statements of Fowler's I was consideriing:

"…the essential point that any object that may be used remotely should have a coarse-grained interface, while every object that isn’t used remotely should have a fine-grained interface."

"If you base your distribution strategy on classes, you’ll end up with a system that does a lot of remote calls and thus needs awkward, coarse-grained interfaces."

“…fine-grained interface doesn’t work well when it’s remote.”

can all be fairly asserted of CSLA. Even though the objects copied to the remote process may have a fine grained interface, the anchored remote object, the course-grained data portal, can only call the mobile object's create, read, update, and delete methods anyway, leaving one with the course-grained remote interface Fowler is describing.

Anyway, it has been helpful to think this stuff through out loud.


planoie January 2nd, 2008 10:58 PM


I'm glad you followed up with yourself, LOL :). I was formulating questions as I read the first longer post, then you pretty much answered them.

Yes, I agree with you. To reiterate, as it helps me understand it as well: The problem is not when we use objects the way you describe, where an object is wired across and a single (possibly complex) operation happens in the remote process (this being essentially a coarse-grained interface). The problem is when we use the members of the fine-grained interface across the process boundaries. What we use will depend entirely on the class design. So, yes, if your objects naturally have a course-grained interface, they are much easier to move out-of-process (given other conditions). Fowler's main point though on that is that in-process classes should be fine-grained and thus not so portable.

This is a very interesting topic. I haven't really worked with remoting a whole lot, so I can't say much from experience. I've been dabbling with it but I'd like to get more proficient. This will certainly help.


Bob Bedell January 3rd, 2008 01:52 AM

LOL. :) Just a little recursive posting.

One caveat. In finally asserting that CSLA fits Fowler's "local fine-grained object interface/remote coarse-grained object interface" model, I am in no way implying that CSLA is an "Errant Architecture" (Fowler's title). I actually have no idea how it, or frameworks like it, perform in a physically distributed environment. I've also only dabbled with this stuff, on a laptop using a local installation of IIS as a remoting host. I've made processes - not machines - swap objects. Can't say enough, though, about CSLA as a tool for learning the .NET "subsystems" (remoting, serialization, threading, reflection, security, COM+ serviced components). There's really no way to grasp how seamlessly these technologies support and collaborate with one another short of diving into a .NET distributed application framework and poking around.



All times are GMT -4. The time now is 11:22 AM.

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.