RE: Matching Records

From: Adam Glauser

I didn't see any O-Specs in yours. Lim's suggestion for the
non-matching part of the query was pretty straightforward, and as
Charles suggested I was getting more fancy than necessary by enumerating
the fields to select when I could have used 'select *'.

Actually, I wouldn't have O-specs, I'd have an externally described print
file. That means I need to create the file, but that's pretty simple. You
could use the same file for an embedded SQL program, I suppose, but then
you'd need to create a cursor and loop through the result set.

If this was a "quick and dirty" you could probably get away with "select *".
In fact, SQL often excels in Q&D tasks. But as you pointed out yourself,
you wouldn't be able to use it in production.

You still need to create a
cursor or run through a result set and print it, not exactly negligible.

It is if you do it regularly, just like remembering the minutiae of MR
syntax is not negligible if you aren't writing that kind of program often.

Okay. I'd be interested to see the full SQL program that would actually
print the report, in which you see each record and an indication of whether
it is an unmatched record, or a matched record with different detail in the
two files.

I think this is a clear case of "to each their own".

<shrug>

Less lines of code, less duplication (and thus easier maintenance), and
probably a lot faster processing as well. Seems to me RPG wins here. I'm
always willing to admit when SQL works better, but this just isn't one of
those times.

As you say, though, to each their own. The real downside to matching
records is that it's so little known these days. It's unfortunate, really.

Joe