RE: Detached datasets and DRDA compliance

> there are quite a few design requiments that are
> suited to "detached dataset".

Some folks take snapshots of their database, export
the files to a "warehouse" and let users run queries
against them.  The detachment is well understood.

Some folks download documents to workstations, modify
them locally, then upload them within a CVS contexts. 
That also makes sense.

Where people run into problems, is where "sets" of
"live" data are downloaded to clients, while other
users may be updating the same data concurrently. 
These applications may give the illusion of being
"live", but don't actually show the current state of
the database, which may lead to minunderstandings, or
one user interfering with the work of another.

Under distributed architectures, which tend to be
poorer performing interfaces, there is a more of a
tendency for programmers to compromise integrity, or
at least concurrency, in order to improve end-user
performance.

Nathan Andelin.










 I have used this type of technique in
> quite a few programming
> languages and on several platforms -- its been a
> while but even RPGIII.
> If you need to support undo/redo, pivot table type
> view/selection,
> multi-systems, fail over or the buildup of complex
> schedules/products
> then a detached dataset is likely to be useful. They
> can simplify
> development and testing and help you provide
> reliable and functional
> applications that perform well.
> 
> As always, there are trade-offs. Performance isn't
> that big of a concern
> locking can be. In a stateless application locking
> isn't trivial but
> there are quite a few patterns that will work. I
> will usually use
> optimistic locking along with some sort of user
> overridable locking
> flag.
> 
> David Morris
> 
> >>> joepluta@xxxxxxxxxxxxxxxxx 06/10/05 7:36 PM >>>
> Thanks, Nathan.
> 
> I'm taking my family out for a long weekend, so I'm
> going to desist from
> the database discussion for now.  However, it seems
> to me that Joel's
> assertion that detached datasets should be used for
> update is fraught
> with peril.  Who handles locking?  Who handles
> update collisions?  It
> seems this is taking huge leaps BACKWARD in
> application design, back to
> the days when users could step all over each other's
> updates, and all
> because distributed databases simply do not scale
> well.  Common sense
> tells you that the more of your data that is on a
> single machine, the
> better your performance.
> 
> But hopefully I can address this in more detail when
> I get back.
> 
> Joe
> 
> > From: Nathan Andelin
> > 
> > BTW, I appreciated your response to Trevor Perry. 
> It
> > seems that the iSeries Network has been drawn away
> > from its traditional moorings lately, forming
> > alliances with sponsors having strong ties to
> > Microsoft, which doesn't sit well with me either.
> 
> -- 
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
>
http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
> 
> 
> -- 
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
>
http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com