Re: Difference between TYPE_SCROLL_INSENSITIVE and TYPE_SCROLL_SENSITIVE ResultSets

"Louis Davidson" <dr_dontspamme_sql_at_hotmail.com> wrote in message news:<XfqdnUk8lqYGgLndRVn-gQ_at_comcast.com>...
> "Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message
> news:c00rgp$11frtc$1_at_ID-152540.news.uni-berlin.de...
>
> > The SCROLLing part of ResultSet in JDBC is a design flaw introduced by
> > the design committee and has no relation whatsoever with a sound
> > programming model,
>
> At their lowest level, even an RDBMS deals with data row by row, column by
> column, and one might say record by record, field by field, since the
> underlying structures are just good old data structures. Obviously SQL is
> set based, and cursors are inherently evie when there are set based
> alternatives, though even the WHERE and SELECT clauses (to name a few) deal
> with data row by row.
>
> Cursors make a great deal of sense to move data from (not to) the relational
> arena to the non-relational since all SQL sets are made up of
>
> > Assuming that ResultSet are intimately connected or similar to a file
> > pointer that moves among the records of the table and you can "update in
> > place", as well as move back and forth, and/or observe updates by other,
> > is unreliable and bad engineering for too many reasons to be discussed
> > here, unless you have a particular curiosity and/or don't trust me.
>
> The real problem is that we are stuck with baggage from the record manager
> days when it was not only common place to edit records like this, it was the
> only way to go. Then they adapted APIs that were good for one thing, and
> while suitable (since the sets that are dealt with look to be the same sort
> of animal as the record based solution,) are particularly horrible from a
> proper software engineering standpoint.
>
> The only problem with this statement is, unfortunately it is much easier to
> program using cursors and updatable sets than it is to build a proper
> interface between UI and data. It is much easier to read in a "set", update
> a value in that cursor, and flush it back to the database server. From what
> I have read here in comp.databases.theory, very few readers here are lazy
> programmers, but unfortunately there are more lazy programmers than good
> programmers (by several orders of magnitude at least!) Clearly when I say
> "easier" I am referring to initial effort, not overall effort, but that kind
> of thinking went out long long ago.
>
> I don't think I can blame the API writers completely, since it is a matter
> of give the fool what he wants (well, the fool with a big wad of cash at
> least) or he will go somewhere else. Plus, the people who made these API's
> for relational databases likely weren't relational programmers. They were
> C++ low level programmers, since for the most part, SQL is not low level
> enough to write an operating system in (sign me up for that project!)
>
> So what I am trying to say is I agree, don't scroll cursors. Using them as
> a method to fetch the set of data from the server is acceptable (the only
> way?) but all of the other stuff you can do with them is for the Foxpro
> guys!
>
> Louis

what? Received on Sat Feb 07 2004 - 03:45:34 CET