Tiny Sidebar to Tony's INV.NUM = (OLD.NUM+1)"R%4" example. One client had this 4 digit limit in their invoice posting routine. The item-id was INV.NUM:"INV" and the [1,4] was pretty scattered throughout their application. The posting program would know the next available number (from a control table) and if the record exists (not paid) it tried the next number. At least this system purged paid invoices.
Under my watch one day the girl noted that the update program was hanging. Sure enough, the posting program was cycling through all 10,000 (0000-9999) candidates for INV0001 and they were all used. Not wanting to repair the [1,4] everywhere, I used the DTX conversion and the number went from 0000 to FFFF which allowed the maximum number to be 65,536 and still be within the 4 digits. I was prepared to further improve on that by using 0-9 then A-Z if necessary. They never got over 20,000 open items. 0-Z for 4 digits is 1,679,616 invoices. My 1 cent. Mark Johnson ----- Original Message ----- From: "Tony Gravagno" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, August 12, 2005 2:22 AM Subject: RE: [U2] Remove Scenario > 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/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
