Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

SQL vs. OPNQRYF--The Battle Continues

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Guest.Visitor
    Guest replied
    SQL vs. OPNQRYF--The Battle Continues

    ** This thread discusses the article: SQL vs. OPNQRYF--The Battle Continues **
    Shops on a tight budget must have BOTH, otherwise they're spending way too much on labor. I know, Sequel (ASC) has made a tremendous impact on reducing backlog in our AS/400 shop. We've also given it to 3 end users that have created wonderful reports, spreadsheets, email, etc. using Sequel. That has reduced our programmer backlog as these users were the ones submitting the most requests. The GUI front end called Viewpoint makes doing all the work very easy. Sequel can be purchased on a "per user" license and a single license for a small AS/400 is very reasonable. Any manager that can't justify Sequel, even a single user license, should find another line of work! BTW, I have no affiliation with ASC other than being a satisfied customer. chuck Opinions expressed are not necessarily those of my employer. "robberendt" wrote in message news:6ae45e52.4@WebX.WawyahGHajS... | Pushing ASC's product might be detrimental for those shops that are on a tight budget. If they had to choose between ASC's product and IBM's 5722-ST1, I'd go for the IBM product for the sole reason to get the SQL precompiler.

    Leave a comment:


  • Guest.Visitor
    Guest replied
    SQL vs. OPNQRYF--The Battle Continues

    ** This thread discusses the article: SQL vs. OPNQRYF--The Battle Continues **
    I was one of those who cheered OPNQRYF when it first came out. But, I haven't touched OPNQRYF for years. I would never consider using it unless there was a gun to my head or a client forces me to. Once I started using SQL, I never turned back. It's so much easier to use than OPNQRYF.

    Leave a comment:


  • tobrien@jackhenry.com
    replied
    SQL vs. OPNQRYF--The Battle Continues

    ** This thread discusses the article: SQL vs. OPNQRYF--The Battle Continues **
    I work for a company that has thousands of AS/400 customers. Why should we expect our customers to purchase an additional product(SQL from IBM) when that money could be better spent on more of OUR products? I don't believe that SQL will be a viable replacement until it is included free with the OS.

    Leave a comment:


  • Guest.Visitor
    Guest replied
    SQL vs. OPNQRYF--The Battle Continues

    ** This thread discusses the article: SQL vs. OPNQRYF--The Battle Continues **
    I have been involved with IBM midrange systems since 1976. I have gone from Mainframes to System/3 to System/38 to AS/400. If we as programmers and developers wish to continue in this business we need to use SQL and SQL tools. SQL is fast becoming the defacto standard for all development. JDBC is based on SQL. iSeries navigator is empowered to use SQL. If I as a hard and fast RPG coder (plus COBOL, Assembler, Fortran and Basic) can learn ILE concepts and SQL then any other computer professional should be able to do so also. It is not enough to rest on your laurals. The writing is on the wall. Learn SQL.

    Leave a comment:


  • robberendt
    replied
    SQL vs. OPNQRYF--The Battle Continues

    ** This thread discusses the article: SQL vs. OPNQRYF--The Battle Continues **
    Pushing ASC's product might be detrimental for those shops that are on a tight budget. If they had to choose between ASC's product and IBM's 5722-ST1, I'd go for the IBM product for the sole reason to get the SQL precompiler.

    Leave a comment:


  • robberendt
    replied
    SQL vs. OPNQRYF--The Battle Continues

    ** This thread discusses the article: SQL vs. OPNQRYF--The Battle Continues **
    I think Paul speaks volumes with this simple statement. While many experienced iSeries developers may feel smug about their knowledge of DDS, OPNQRYF, etc. I am finding that the new people here faster to adapt to SQL.

    Leave a comment:


  • robberendt
    replied
    SQL vs. OPNQRYF--The Battle Continues

    ** This thread discusses the article: SQL vs. OPNQRYF--The Battle Continues **
    What does come with the base operating system? - The ability to run sql scripts with RUNSQLSTM - The ability to run sql scripts with iSeries Navigator - The ability to create Query Management Queries with CRTQMQRY - The ability to run Query Management Queries with STRQMQRY - The ability to convert Query/400 queries into source with RTVQMQRY - The ability to set up referential integrity - The ability to use triggers - The ability to interactively run sql statements with iSeries Navigator - The ability to use sql in programs with the Call Level Interface (SQL-CLI). Albeit somewhat clunky. - The ability to graphically change your databases by adding/modifying/deleting fields by using iSeries Navigator - The ability to graphically see how one file is related to another by seeing the referential constraints by using iSeries Navigator. What does come with 57##ST1? - The 5250 prompter for SQL - STRSQL. Many statements cannot be prompted, yet still run, there. - The SQL precompiler for many languages. Much easier to understand than SQL-CLI. However often languishes behind the compiler release. - The prompter to generate Query Management Queries - STRQM. A competitive product to Query/400.

    Leave a comment:


  • Guest.Visitor
    Guest replied
    SQL vs. OPNQRYF--The Battle Continues

    ** This thread discusses the article: SQL vs. OPNQRYF--The Battle Continues **
    I would just like to add my 2 cents worth. I am a 20+ year veteran of the programming world using COBOL, RPG, BASIC, SQL, on different machines from UNIX/LINUX, HP9000, IBM370, IBM43XX, etc. I have tried most tools available, and I have to say that the only thing I like about the AS400 is the ability to use ASC's SEQUEL. The AS400 is a stable machine, but very hard to get the information you need from, unless you have spent a long time with it. I do admit I have only worked on the AS400 for the past 13 months, but without SQL I wouldn't be able to use my experience from the other environments... Paul

    Leave a comment:


  • David Abramowitz
    replied
    SQL vs. OPNQRYF--The Battle Continues

    ** This thread discusses the article: SQL vs. OPNQRYF--The Battle Continues **
    SQL/400 has been around for a while now, and really hasn't caught on with most AS/400 shops. The reason is basic. That is the *BASE features of the AS/400, i-series, etc. does not include SQL! DDS, and OPNQRYF are part of the base OS, and until SQL becomes as accessible, it will not be used. Dave

    Leave a comment:


  • Guest.Visitor
    Guest replied
    SQL vs. OPNQRYF--The Battle Continues

    ** This thread discusses the article: SQL vs. OPNQRYF--The Battle Continues **
    ** This thread discusses the Content article: SQL vs. OPNQRYF--The Battle Continues **
    0

    Leave a comment:


  • Guest.Visitor
    Guest replied
    SQL vs. OPNQRYF--The Battle Continues

    I can put an OPNQRYF statment in a CL to add filters to an interactive pgm or reports and elimate the need to change the RPG pgms that follow. This is faster and easier. It also makes it better for the next guy who follows. I do use SQL embedded in RPG. I find it cumbersome to retro-fit in this scenario. Bottomline I use & know both. The main point is, it sure would be nice to have SQL supported fully in CL with dynamic variables, why would anyone disagree with this point??? robberendt- I like SQL but I won't go out of my way to use it when OPNQRYF is the best answer. It is the best answer in some cases. Some esoteric way to use a free third party tool to build a string with dynamice variables then execute an API I'm guessing is not the soloution just to dodge OPNQRYF or to say you can in fact use SQL in CL w/o limitations.

    Leave a comment:


  • ukpi1b
    replied
    SQL vs. OPNQRYF--The Battle Continues

    Some notes to discussion. 1. One has to get an idea how data looks like before writing any program. You are lucky if your shop has DBU or any other utility. There are plenty examples when the only available tools are DFU, QRY400, QMQRY. You still can create SQL looking like tool within CL and QMQRY at no cost at all. OPNQRYF uses dummy file to join several files. It is much easier to use SQL to get data for this join even with EXSQLSTM. 2. SQL is great tool for testing. In some cases, couple SQL statements could replace several pages RPG program and any step could be easily verified. I have never seen OPNQRYF as a part of testing procedure; usually it is OPNQRYF selection that needs to be tested. 3. I still use SQL and OPNQRYF because of client requirements, company policy or standards.

    Leave a comment:


  • coteijgeler@chello.nl
    Guest replied
    SQL vs. OPNQRYF--The Battle Continues

    I have to respond on this. I do not think you can compare OPNQRYF and embedded SQL entirely. Both make use of the same query engine on the AS/400. OPNQRYF file has the limitations of CL, as it is a CL command. It will not deal with data types like floating point or integers. I see OPNQRYF as an interface to SQL in CLP, and it fulfills two SQL functions: prepare an SQL statement and open a cursor. To process the open data path you need a HLL language. If you want that OPNQRYF is as flexible as SQL, then IBM have to enhance that CL command. But then it should enhance other CL commands as well, which it has not done for a long period now. I agree with you, that using OPNQRYF is cumbersome, but so is embedded SQL in an RPG programme. Just my two Euro-cents. Regards, Carel Teijgeler

    Leave a comment:


  • J.Wells
    started a topic SQL vs. OPNQRYF--The Battle Continues

    SQL vs. OPNQRYF--The Battle Continues

    Thanks, I will take a look. Joe
Working...
X