×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
In fear of starting a lengthy thread I'll respond about this:
It goes along with what Joe is saying about being careful in the use of
powerful tools like SQL. In this case, the original programs were RPG
programs that could only be run by a handful of people. More recently
however, they have added a couple of Java programmers and the main
technology department head learned a few SQL "tricks". They had fallen
into the practice of running "quick SQL updates" to make some mass
changes to things like dates and account numbers that change this time
of year rather than "memorializing" them into stored procedures that
took parameters or writing RPG programs that maintained the records
properly. You can imaging what this has led to. So, the past 4 weeks
the programmers and the department head are on vacation and I (as a
consultant) have inherited the effects of the "tricks". Orphaned
records, things out of sync, etc. That is a result of the "quick SQL"
practice, a lack of knowledge about the database and well as just a lack
of discipline. So, I am trying to find out where and why these things
occurred, fix the "fallout" and also give them front ends and tools that
consistently run these "quick fix" procedures.
Back in the day, there were no "quick fixes" and so we'd resort to an
RPG program, even if it was a "one off" situation. The good news was
that if the "fix" was needed again, it ran exactly the same way and
wouldn't incorrectly update thousands of records if someone accidentally
fat fingered a value (well, if there were proper edits in place). So, I
am attempting to bring some order back to the chaos here: Identifying
those things that are out of whack, researching and fixing them and
writing RPG front ends to properly edit as well as write SQL that
properly maintains the the relationships (without the benefit of
referential integrity).
Yeah, I could just write RPG to do the whole thing but, properly
implemented, you can get a whole lot more accomplished with an SQL
statement sometimes. It's all RPG, even with embedded SQL, anyway.
Pete
Walden H. Leverich wrote:
I have a situation where I have a quantity field in the
detail that I want to sum and then update the header.
Others have pointed out how to do this (and it even sounded like Joe
_liked_ SQL :) but this also raises the question, why are these out of
sync in the first place, and should you actually be asking about a
trigger on the detail table that keeps the header table in sync
automatically? Just something to think about.
-Walden
midrange.com
