Hi Joe,

I hope you have had a nice weekend. 

Single system and simple is always best if it meets your needs but there
are quite a few design requiments that are suited to a "detached
dataset". 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

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.


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


Return to Archive home page | Return to MIDRANGE.COM home page