Actually Tony (Gravagno) you are hitting the target very closely. This TPH application has hundreds of programs in the application and the original designer, who's still here, endorses using it for existing and new work. I buck the trend as I'm not up to speed like he is on TPH but it's sort of the home court advantage.
While TPH is a 4GL (please no flames or deviations here), it does allow for beaucoups of hand code or external subroutines. I wrote one last week called GET.AR.BAL that incorporates the popular REMOVE statement to jog through this mess and get the a/r balance in 8 seconds instead of 8 minutes. So I am inserting this whenever the a/r balance is desired. I can replace this Cash Reciepts program with hand-written code in around 1 day. I have to sell this concept or bury it in my other work. Plus I have to survey the users to see how it really affects them. Their top busiest customers have 150,000 - 90,000 - 40,000 - 20,000 and 9,000 invoices respectively. Their most important customers are the top 2 guys. And yes, they are billing on the sale order lines instead of the complete sales order. Can't change that as each line to the customer is a complete 'order' and my guy bunches up all the orders on a master delivery order (300-800 per day) but the customer can pay or challenge any one of these line-level orders. Unless a MV technique shows up that is the opposite of REMOVE I will follow my BIG(X)<1> example. I like to solve inherited problems at the program level instead of trying to re-engineer the data files and make sure I get to all of the programs. It's only a cash receipts program for pete's sake. (I'll do the same for the a/r inquiry program). For those who care, the daily invoicing does not append to this xref file at that time. There is an overnight process that clears the xref and rebuilds it for the next day. It's not likely that they will apply cash to an invoice billed minutes earlier. Plus, the REMOVE is behaving properly for extracting the 50,000 from the pool of 150,000. It's the building of these TABLE variables inside the program that's the current issue. I solved this very issue with my original employer in 1983 by switching from EXTRACTs to using a combination of DIM and Dynamic array like I've shown with BIG(X)<1>. Back then a microdata only had room for 1,500 variables so you could not DIM BIG(1501). Now-a-days these limits are relegated to Jurrasic Pick. BTW, their A/P is on Quickbooks as from my observation, the original programmer wasn't that good at accounting and they decided to not invest his time using TPH (or any code) for A/P on MV. And, yes they pay promptly. Thanks 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/
