But Andrew, can you name anything other than that that it lacks? It's about the only limitation listed here:
http://developers.sun.com/javadb/features/faqs.jsp (Derby is known also as Sun's JavaDB, as well as formerly--and still-as IBM Cloudscape.) Really, I just think you're stuck on this TOP thing. Would you be shocked to learn that many developers could go years without needing or using the TOP predicate in SQL? I have, and I'm sure I'm not unique. (There've been other DBMS's over the years that didn't support it at one time or another, so some just have gotten used to accepting a lowest common denominator and programming around such a challenge.) You just keep saying Derby's got "serious limitations", yet I don't see them. Since I keep pointing to things that show so much that it's capable of, I'm just asking if you can point at something that says what it doesn't do. I simply want people to be able to decide for themselves, not take either of our assertions as fact. That's all. As for using a cached query, goodness, why would you be averse to that out of hand? There can be times when it may not be wise (a huge result, or too many variations stored over and over), but I can totally argue in favor of using cached queries (whether in a shared scope or using CachedWithin) if done well. You seem to live in a world of absolutes, Andrew. :-) As a consultant, I can't help but be more flexible and say always, "it depends". Again, in that regard, I'm all about sharing info to let people decide for themselves. /charlie -----Original Message----- From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Scott Sent: Wednesday, December 05, 2007 9:23 AM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: Derby Embeded Database (CF8) and Eclipse/FlexBuilder Charlie, No I am not getting hot under the collar, I made a very healthy statement that means that people will seriously need to take into consideration when it comes to Derby. To not support the most basic of retrieving the top n records (whether it be top n or offset n) to me is young, regardless whether the application has been around for 10 years or not. Don't get me wrong, anything that is open source is seriously worth a look at. Just that in this case people need to be aware that there a serious limitations to Derby, that when compared to mySQL, postrgress, msSQL, informix etc. It is young at heart, because it has a long way to go to be compariable to those DB's. As for Geoff, I bawk at anyone who says to cache the query and do a QoQ on that query. It might be a quick fix for now, but in the long run it is not a quick fix and should be refactored to be the best solution as quickly as possible. There is a good book that is out there on Software maintenance, and why one should not look at a band aid solution. Geoff's example, to me is a band aid solution and should be avoided at all costs. Again if I came across angry, it wasn't my intention. On 12/5/07, Charlie Arehart (lists account) <[EMAIL PROTECTED]> wrote: > > Andrew, you seem to be getting awfully hot under the collar over all this. <snip> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
