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 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 mailing list archive is Copyright 1997-2015 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact