Re: Should I replace all CHAIN, SETLL, and READs to SQL

I guess I'm a lazy programmer, you see I've adopted SQL for data access because it seems simpler and, for the most part, cleaner then RLA. I've been in the business since the System 360 days and can't tell you how many times I've had to debug a program because it failed to select a give record because it happened to be the second Tuesday of a 30 day month of an odd year. Or better yet, you write a program that reports a subset of total sales and the user says its wrong because the number you're reporting doesn't match sub total value from the total sales report. If you build data views and verify the results, then you can always produce consistent results.
Now don't take this wrong, SQL and RLA are tools and both have their uses. For example, If I need to verify existence I'll use the SETLL op code, rather then construct and SQL select and fetch routine. Why, in the last few months, I've actually written a program that has an Input Primary file.

It is my belief that SQL has become such a popular tool because
1) Machines have become so fast that forcing the database engine to look through thousands of records to find the one you're looking for takes no more noticeable time than a CHAIN, or SETLL and READ.
2) The "IN" languages, and "IN" database engines of the day do not support what used to be called VSAM. The only method they have to process data randomly is through SQL.

A long time ago I read an Intro to Data Processing book (circa 1958). he book is ancient history now but the author said one thing that really stuck. He was raising a warning about trying to do everything with the computer and it went something like this - When all you have is a hammer, everything looks like a nail.

On Nov 5, 2012, at 4:27 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Alan Campin
Every AS/400 shop. Absolute agony about making a change to a table.

You might gain more traction if you were not so predisposed to absolutes and hyperbole. In the SQL vs. RLA debate there are no real absolutes either way. Both have appropriate use cases. You're raising artificial barriers against RLA by ridiculing it and urging all DB I/O to be handled by SQL alone.

We use both SQL and RLA and don't agonize over changing table layouts. We're pretty agile with respect to changes to table layouts. We use a utility to scan RPG source members that would be affected by table layouts, and optionally compile them automatically. There typically aren't a lot. We encapsulate DB I/O appropriately. We use SQL in modules that generate filtered lists and reports, so none of those source members are affected. We don't recompile "the world".

-Nathan

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.