|
Joe, I always read your posts with interest, and normally I agree with (at least most of) what you say, but I have to disagree here. Of course, we're just talking about our opinions here, so there really isn't any "right" or "wrong", but in comparing SQL and OPNQRYF I think SQL wins hands down. I think the reason you don't see many questions about OPNQRYF is that the only people who use it any more are people who know it and are comfortable with it -- no one else would go near it unless they were forced to, and now that we have SQL we don't have to. I have seen people create single-use logical files just so they didn't have to use OPNQRYF, and I have seen people spend hours trying to debug OPNQRYF statements. OTOH, in fairness, I have also seen it used effectively, and I agree completely that the main goal is to use the right tool for the right job. I also agree that for record-by-record processing, SQL is a bad choice -- I'm 100% with you on that. But nowadays if I want to write a report that allows a user to enter a few selection criteria and pick a sort order and then pulls data from, say, a transaction file and a couple of master files, I'll pick embedded SQL over constructing a READ loop with multiple CHAINs every time (and I used to do that rather than use OPNQRYF). I can construct a simple statement (using PREPARE even allows me to construct it on the fly), the performance is fine, and readability is largely determined by how I format my statement (personally, I'm a big fan of groupings, indents, etc.). I think the reason we see so many questions about SQL is that a lot of people see its potential and they're trying to learn it. The same thing happened with RPGIV -- remember all the discussions of EVAL and BIFs and string handling and all the other goodies? Another factor is people trying to push things to the limit -- IMHO, the quest for the "single SQL statement" is often more of a puzzle-solving exercise than a practical solution to an actual problem (but I like puzzles, and I have learned a lot from them :-). And let's not forget career enhancement -- SQL is used in an awful lot of places, and should (heavens forbid!) the supply of RPG programming jobs dry up in my area I'd like to have _something_ other than my boyish good looks to recommend me to another employer. . . . ;-) Is SQL syntax arbitrary and obscure? Well, I think that depends on one's point of view and experience -- if you've never seen it before, the answer is probably "yes", but how is that different from RPG, CL, OPNQRYF, C, Java or any other programming or database-management language? (Or for that matter, any language at all?) Once you get used to it, it makes a lot more sense, but that takes time and effort. Personally, I think SQL is pretty understandable -- it's certainly possible to write obscure statements, but then it's also possible to write obscure RPG programs, so I don't really think that counts as a failing. . . . JMHO Joe Pluta writes: >You're right, sort of. OPNQRYF requires an OVRDBF. Dunno what else >you're >referring to. As to file vs. format, I've never had a problem figuring it >out. Guess I read the manual at the beginning and it stuck with me ever >since. > >You're opinion about new people finding SQL easy to use is just that, by >the >way, and isn't supported by the facts. Check the forums and see how many >questions people ask about how to get SQL to work as opposed to how many >questions are asked about logical files or even OPNQRYF over the years. >You'll find that for many people, SQL is confusing and difficult to >understand . . . Mike Naughton Senior Programmer/Analyst Judd Wire, Inc. 124 Turnpike Road Turners Falls, MA 01376 413-863-4357 x444 mnaughton@juddwire.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.