Tim Young [Elevate Software] wrote:
> Dave,
>
> << Isn't the need to manage the cursor the result of an undesirable side
> effect? I used to do this with Clipper years ago. At the time, it always
> seemed wrong or lacking, and that there should have been a better way. >>
>
> It depends upon what you mean by "manage the cursor".  If you mean
> navigation, searching, etc. then there really isn't any way around that.
> Every access to a cursor on any dataset is going to require cursor
> management to some degree.  MS has tried to remove this type of access with
> respect to .NET and the way that they handle data retrieval, but it is
> really counter-intuitive in many ways because it tries to make datasets that
> are from a database (and can be quite large) behave like in-memory datasets.
> This basically eliminates the ability to ever look at the dataset in its
> entirety for any practical purpose without resorting to pagination schemes
> that effectively force the end developer to recreate the code that the
> client interface layer has managed *for them* for years.  IOW, eliminating
> the pagination and scrollable cursor support that ODBC and other standard
> CLI access layers have always had in the past didn't get rid of the
> requirements for such things, it simply moved the responsibility out of the
> hands of the database engine developers and into those with the least amount
> of experience in coping with such issues - the application developer.  Now
> with .NET the application developer has to come up with all sorts of
> pagination schemes to work around the fact that the data access layer does
> not provide scrollable cursors.
>

I'm wasn't talking about removing navigational style capabilities.
Sometimes it comes in handy. What I had in mind was stuff that violates
basic ideas from Comp Sci 101: side effects from the use of global data.

Say there is a customer table. One form uses this table to edit and
append. Another form uses this same table for lookup. Another for some
kind of display. In this scenario functions are written so as to save
and restore the record position. This is error prone and filled with
potential side effects. Better to have separate tables/datamodules and
treat things as multi user. I don't like having code in one place
breaking code in another, with the only way to avoid it being that I
have to remember to add housekeeping code. I won't remember six months
later.

Actually I know very little about .net, and am just starting to look at
..net, so I'm not sure what kinds of "warts" might be there.

I do wish that Delphi allowed binding controls to objects, similar to
..net, while allowing design time support. The lack of this support means
that Delphi breaks basic Data Structures 101 stuff, specifically
encapsulation/information hiding. It's less than ideal when there is a
customer object, whose internal database fields are directly bound to
controls. It also means I have to catch every event to make sure nothing
slips thru. It also doesn't help for testing. The whole "datamodule
thing" needs an update and tends to promote problematic coding
practices. It was clever when it was invented, but it was never good
practice. That was my whole point in the thread.


Dave M.

Dave,

<< I'm wasn't talking about removing navigational style capabilities.
Sometimes it comes in handy. What I had in mind was stuff that violates
basic ideas from Comp Sci 101: side effects from the use of global data.

Say there is a customer table. One form uses this table to edit and
append. Another form uses this same table for lookup. Another for some kind
of display. In this scenario functions are written so as to save and restore
the record position. This is error prone and filled with potential side
effects. Better to have separate tables/datamodules and
treat things as multi user. I don't like having code in one place breaking
code in another, with the only way to avoid it being that I have to remember
to add housekeeping code. I won't remember six months later. >>

Ahh, I misunderstood what you were saying.

<< I do wish that Delphi allowed binding controls to objects, similar to
..net, while allowing design time support. The lack of this support means
that Delphi breaks basic Data Structures 101 stuff, specifically
encapsulation/information hiding. It's less than ideal when there is a
customer object, whose internal database fields are directly bound to
controls. It also means I have to catch every event to make sure nothing
slips thru. It also doesn't help for testing. The whole "datamodule thing"
needs an update and tends to promote problematic coding practices. It was
clever when it was invented, but it was never good practice. That was my
whole point in the thread. >>

I agree in that respect - binding directly to objects would be nice.

--
Tim Young
Elevate Software
www.elevatesoft.com