Well, I found the "magic answer" as to why it's so oddly designed. This is NOT a rant, but an aha! moment...

I used to have to re-program these things as well. It's spaghetti code, or Topsy programming (it "just growed.") Nobody ever sat down and said, "this code is from an Atari 6502 8-bit machine with a DOS overlay and a Windows NT overlay on that. It's why the window looks Win 3.1 and the data looks like dBase II.

I'm not dealing with a system. That was my mistake. It's a collection. I wanted to find consistent conceptualization where there is none. And that is not to put the program down, but to recognize the actual status. It's not a system, it is a set of unrelated programs that share common datasets and a pieced-together GUI. The authors of section A are unaware of (or don't care about - or aren't allowed to care about, depending on the shop) the section B or C programs.

I have to learn the programmers, not the program. That's fine, I once had to write a FoxPro app that linked a local SQL database with two different State mainframe apps, one in Sacramento, one in LA/OC, as filtered through four different local departments. And just about EVERY line of code in the state apps was patched more times than a $5 used tire. And even THAT was fine until the Country mandated that I had to convert the whole furshlugginer mess to Access, FoxPro's weak sister... eek

Bottom line - after first performing all the tasks you had outlined above and rebooting, then hitting reset, things may be looking up. More to follow, but thanks for the help.

Last edited by The Soundsmith; 09/14/14 04:09 PM.
It's all about the music.
(I keep telling myself that...)
http://www.davidkempton.com