Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

SQL vs. OPNQRYF--The Battle Continues

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

  • SQL vs. OPNQRYF--The Battle Continues

    Thanks, I will take a look. Joe

  • #2
    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

    Comment


    • #3
      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.

      Comment


      • #4
        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.

        Comment


        • #5
          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

          Comment


          • #6
            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

            Comment


            • #7
              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

              Comment


              • #8
                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.

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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.

                    Comment


                    • #11
                      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.

                      Comment


                      • #12
                        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.

                        Comment


                        • #13
                          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.

                          Comment


                          • #14
                            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.

                            Comment


                            • #15
                              SQL vs. OPNQRYF--The Battle Continues

                              ** This thread discusses the article: SQL vs. OPNQRYF--The Battle Continues **
                              I agree that SQL is a strong language and I use it on a daily basis. However, as far as being the source for creating files, I have a few issues. RPG programs are pretty nasty about File Identifiers. We use 3rd party software (JDEdwards) and one of their products uses DDS to create files and their other product uses SQL to create tables. If we try to run an RPG program from the one set of software, over a table generated from their other software, we have problems due to format level id's and format names not matching. Maybe it's just JDE's tool for creating tables using SQL that is not using the correct naming conventions and keywords? Would you save the SQL statements you use to create files in a source file so that you could create the same file with the same format info in different libraries or testing environments and systems (which may have different operating system levels)? Another use for DDS is documentation and data dictionary. When you create a DDS field name reference file and then design all of your files using DDS referencing your original member, you know that a particular field will be created the same throughout the database. I'm not good enough at SQL to be able to use a reference file for fields within a table.

                              Comment

                              Working...
                              X