Re: Detached datasets and DRDA compliance

On 6/10/05, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:
> This is an interesting point, Steve.
> 
> > From: Steve Richter
> >
> > I dont think it is an openness issue.  DRDA, I am guessing, is part of
> > a server centric architecture.  Since the release of  ADO.NET ( 5
> > years ago ) and probably SQL Server 2000  Microsoft has gone with the
> > detachable dataset approach to database serving.  They say such a
> > database setup is more scalable and is more compatible with server
> > farms.
> 
> Not sure yet about the server farms issue... I need to think about that.
> But from a standpoint of pure server load, you're saying that the
> overhead of storing the result set on the server and sending it over to
> the caller on a request by request basis is higher than that of creating
> the entire dataset and shipping it as a detached set.
> 
> On face value, you seem to be correct on that.  Of course, that's really
> only useful when you have bounded sets; that is, sets of data where the
> requester already knows the beginning and end.  That's a bit different
> than the concept of a scrollable cursor, or even an updateable cursor.
> Detached commitment control isn't going to work very well.
> 
> But for that segment of the application suite that is read only on small
> but complex datasets, I can understand the detached set concept.
> However, since you still need both scrollable and updatable cursors for
> any sort of real development, this argument against server-side cursors
> (and DRDA) seems to be less feasible.

Hi Joe,

I am out of my depth on the subject.   Here is MS blogger who seems
like a regular guy and has some good content on his site.  You have to
dig a little to find it.
http://betav.com/BLOG/billva/

What I do know a little bit about is the programming side of this
issue.  As much as I respect MS I am not sure how comfortable I would
be coding large scale database apps in .NET.  My code consists of a
lot of this sort of stuff:

row = new SessionHistoryRow( ) ;
row.SessionId = reader.GetString(0);
row.UrlReferrer = reader.GetString(1);
row.PageCx = reader.GetInt32( 4 ) ;
row.StartTs = reader.GetDateTime( 5 ) ;
row.EndTs = reader.GetDateTime( 6 ) ;

I have snipped a lot, but basically to read a row from a table, you
load up an "SqlCommand" object with the "select * from table where
xxxx = yyy" statement. After running the SqlCommand your code gets
back the dataset.  From the dataset you then run code that pulls the
rows and columns out and into your program variables.  That is what
the above code is doing.

The problem is, you refer to everything by ordinal value or literal
column name.
  reader.GetString( 0 ) ;  // get the value of column 0 in the current row.
  reader.GetInt32( "OrderQty" ) ; // search for the column named "OrderQty" ...

Your code also needs to know the data type of the column. Is it
decimal, SqlMoney, integer, string, dateTime, ...   Hopefully Walden,
our .NET guru, can correct me, but it appears to have a lot of
potential for hard coding issues.

If you have access, this video looks interesting:
http://channel9.msdn.com/ShowPost.aspx?PostID=10276

I actually have not watch the video yet, buy Anders Hejlsberg is the
C# architect at MS.  The topic of the video is part of what he has
been talking about a lot lately, how C# has to be improved to better
integrate database access into your code.

-Steve