>Thanks for the explanation. I work with a number of typically small companies, and I like to ask simple questions so I can figure out what they do, rather than how they do it. From time to time you find simple workarounds around out-of-control technical processes or even find out that chunks of what they were doing are completely unnecessary.

Couldn't have put it in words better than this. I've had a few customers who insisted on transferring their manual processes into the code, and in most of the cases these were redundant, or completely unnecessary. Some of their procedures were designed to check for errors which couldn't have happened while computing (what's the point of totalling the stuff two ways, if you're totalling the same records?), and then there were some of our checking procedures which they didn't accept until they made the errors these were designed to catch.

It's as if they're using brushes and you're using a spray can, and they want you to show how do you remove hairs which fall off. And they don't want to know about air filter, because they don't need it with the brush. Very hard to explain this type of situation to an user, specially in places where they have some procedures unchanged for a couple of decades, those who invented them are long gone, and those present never knew the reasons for these procedures.

But when you can push your solution through, it's really rewarding.

>Wasn't it DF who said, "the best code, is no code"?

That's a good one. And it's true.