Re: Copying code into SQL statements

I am ashamed to admit the genesis of this side excursion was, in fact, a
SELECT * (sorry, Charles!) in a special app that allows a user to clone
pricing data, and I wanted to ensure I wouldn't miss any column. After a
database change, my automated process failed to recompile this program
which had failed unexpectedly.The performance impact of SELECT * wasn't the
issue; it was the missed compile.

From time to time, I update my database layout. I like to do that as a

standalone project, usually in advance of other projects relying on an
updated set of tables, so I can control when certain applications go
offline. And while we don't have to deal with CPF4131, I like to recompile
programs using the changed tables. I like to find problems early (except
as noted above, when I didn't).

SQL appears to populate every defined column, even the unreferenced ones,
and that's come in handy more than once when debugging. That's one of the
reasons I like to have all columns visible--seeing the change timestamp
(which isn't used in every program) can be useful.

Did I mention the machine-generated code includes the text description?
That's very handy in-line documentation and extraordinarily useful to
programmers digging into the program for the first time. I have a code
generator that creates. in one big source member, several dozen snippets of
SQL and RPGLE code from a list of columns and descriptions (this tool has
saved me hundreds of development hours and eliminated "a lot" of lint-type
errors introduced when a bleary-eyed programmer transposes characters in a
complex SELECT). Today I copy-and-paste; tomorrow, maybe INCLUDE. It's
all AI, with no "A" and sometimes a deficit of "I".

I have experimented with a tool that identifies unused SELECT'ed columns.
If/when I get it working, I'll probably hard-code referenced columns again,
primarily for performance.

On Fri, Mar 21, 2025 at 2:21 PM Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

It's good that you don't want to use SELECT *

But you also should not need "every column" very often if at all. (And the
exceptions where you do need every column might actually be an exception to
the don't use SELECT * rule)

Best practice in the SQL world is to only SELECT the columns you actually
need.

I've got a little routine that generates an RPG data structure from
SYSCOLUMNS, once you've got a full DS someplace, getting just the subfields
you need isn't a big deal. Maybe I'll clean it up and post it someplace...

For the SELECT, prompting in ACS RSS is usually my quickest way of getting
a list.


Charles

On Fri, Mar 21, 2025 at 2:09 PM x y <xy6581@xxxxxxxxx> wrote:

Instead of SELECT * or listing every column name, I'd like to put the
column names in a source member and "include" it in the main SQLRPGLE
compile. The source members are machine-generated; I'm doing this to
reduce the maintenance workload.

"from_src" is "a,b,c". "into_src" is ":a,:b,:c".

INCLUDE works with SELECT:
SELECT
INCLUDE from_src
INTO...

but the preprocessor won't accept
INTO
INCLUDE into_src
WHERE...

The error is SQL0104 and the preprocessor is looking for a comma or an
INTO. I have my INCFILE set correctly.

Using
FETCH NEXT FROM THIS_CURSOR INTO
into_src...

INCLUDE is tagged as a variable not found.

Am I missing something other than using dynamic SQL? It's just a

reminder

of how incredibly productive DDS is!
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.