Mark Johnson wrote:
> Here's a doozy.
Mark, the fundamental problem is that the original code wasn't designed for
the application that it's being asked to do now. That construct that you
describe "EQU INVNO.TABLE TO CUST(40)" is something that experienced
developers simply don't use anymore because it's such a bad idea. That
code was written for small companies and when they get larger it falls
apart as you see. It's like generating invoice numbers like this:
INV.NUM = (OLD.NUM+1)"R%4"
Anyone remember day 10,000?
While it's a good exercise to understand the underlying MV mechanisms, I
think the real solution to this problem is not to try to bully a bad
architecture, but to re-write it for its current environment. We "can"
process 50,000 elements with 15 attributes, but should we do so? Only if
absolutely required, which isn't the case here.
If nothing else, you need to separate open invoices from closed invoices in
that single attribute in the Customer record. Get the closed invoices out
of the record and only hold the open ones. The best way to solve this
however, is to store invoice keys in a key file, not all in a single
record.
In real life you're going to have a hard time telling your new formerly
orphaned client that some of their TPH code needs to be re-written rather
than just optimized to run faster. Been there, done that. But if you can
re-write it so that the end-users get virtually zero delay when processing
cash receipts they'll thank you for it. BTW, the same code can probably be
applied to disbursements if your payable invoice ID's are stored in your
Vendor records like that too.
BTW, if you have a client with 50,000 invoices for a single client then I'd
guess they won't choke too hard on some real coding vs funky patches to a
bad schema. If they have 50,000 _open_ invoices for a single client then
I'd further guess that they have a serious problem with their accounting
practices, unless they're a "one line item per S/O" shop, and you might
might want to check to make sure they aren't having similar problems paying
their vendors, if you know what I mean. ;)
Not much help, sorry.
T
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
