you'll see why when you start debugging it and totaling up the invoices for multiple sites, multiple invoices, etc... <grin>
On 3/24/2010 4:08 PM, Kurt Wendt wrote: > But - Virgil - Cursors act largely like a Temp DBF - so, I see no reason > not to use a Cursor over a Temp DBF - exact in the case of what I am > trying to figure out here. As in - will it slow things down too much - > with too many records and TOO Many Queries made to it - during the > processing of a SINGLE Invoice... > > -K- > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Virgil Bierschwale > Sent: Wednesday, March 24, 2010 5:03 PM > To: [email protected] > Subject: Re: Large # Rec's, Cursors& UR Opinion... > > thats why you're going to end up doing it exactly like what I just > spelled out... > too much to keep track of in cursors. > > I'm sure others will disagree, but the old ways work best some times in > my opinion. > > > On 3/24/2010 3:45 PM, Kurt Wendt wrote: > >> Virgil - understand that I'm not writing a full invoicing program - >> > but, > >> rather - I need to plug-in code within the whole invoicing that >> > already > >> exists. And there are Multiple programs - due to multiple types of >> Invoicing (by Pick Tickets, or by specific lines, or by store, or by >> Style, etc.). >> >> Although, maybe you are just saying to use Temp DBF's - as opposed to >> > my > >> using a Cursor? >> >> -K- >> >> -----Original Message----- >> From: [email protected] >> > [mailto:[email protected]] > >> On Behalf Of Virgil Bierschwale >> Sent: Wednesday, March 24, 2010 4:26 PM >> To: [email protected] >> Subject: Re: Large # Rec's, Cursors& UR Opinion... >> >> I did a similar deal for a company that invoices Siemens with 1,000's >> > of > >> invoices per month about 2 years ago. >> except for the fact that they are now invoicing canada and we had no >> plans for that, it works without a hiccup. >> >> I don't have the code with me right now but I can get it.. >> >> basically I took the header and detail tables from the a/r system and >> then I had two tables I would zap every time before starting. >> do a do while or end scan on the a/r system and append the data to the >> two blank tables with some fields added to keep track of things.. >> then once the tables were populated, I would scan through them and >> > write > >> the lines out to a text file in the format they expected.. >> >> first line was the company that it was coming from and the last line >> > was > >> the totals of all lines >> lines 2 and 3 were the header and line 3 would be multiple detail >> > lines > >> sometimes.. >> >> Piece of cake. >> If memory serves me correctly at 25 per hour it cost them about 3,400 >> two years ago. >> >> Thought we were going to do a new rewrite recently because siemens >> changed to a EDI 12 (I believe it was) requirement, but apparently >> > that > >> fell through >> >> >> On 3/24/2010 3:12 PM, Kurt Wendt wrote: >> >> >>> Hey folks, >>> >>> >>> >>> I'd like to get people's Opinion - or a little input - on this thing >>> >>> >> I'm >> >> >>> trying to tackle. >>> >>> >>> >>> One of our clients has a request from their Trading partner >>> >>> >> (Burlington >> >> >>> Coat Factory) - having to do with sending back their EDI Invoice. >>> > What > >>> it boils down to is this complicated issue that multiple Invoice >>> > lines > >>> must be considered together when calculating the Dollar amounts >>> >>> >> getting >> >> >>> sent back via EDI. The problem is that they have these kind of >>> PrePacks/Assortments. And, normally - for the processing of the >>> >>> >> Invoices >> >> >>> - each line is considered by itself - and calculations made. >>> >>> >>> >>> So - for the changes I need to make to the Invoicing - I'm building >>> >>> >> this >> >> >>> Cursor which I will use for the lines that require these special >>> calculations for the Shipment $ amounts. The problem - is that for a >>> particular Sales Order (the one I am looking at) has 5717 lines. And, >>> they could invoice the order by specific lines, or by Stores (there >>> >>> >> are >> >> >>> LOTS of Stores in this particular Order), or by a group of different >>> styles. And, this Cursor I am using to group the Lines together for a >>> PrePack - I will have a flag in the Cursor Records - so that I only >>> >>> >> run >> >> >>> a calc once per the group - but, when the processing hits one of the >>> other styles for that Group - it will skip the calc and just pass >>> > back > >>> Zero. >>> >>> >>> >>> During the invoicing - I could be hitting that Cursor A LOT - and if >>> >>> >> it >> >> >>> starts to get big (like, for instance - if their selection ended up >>> including 3000 of the original 5717 records) - I think the searches >>> within that Cursor may start to get slow! (At 3000 Records - I would >>> essentially hit that Cursor 3000 times to Search for each record - >>> >>> >> which >> >> >>> doesn't include when I add in the Records). And - I think this could >>> >>> >> end >> >> >>> up being REALLY Slow. And, I prefer to make optimized code that >>> >>> >> doesn't >> >> >>> slow to a crawl. >>> >>> >>> >>> So - is just searching a Cursor of 3000 records like that - would it >>> >>> >> end >> >> >>> up being relatively slow (especially if searched between 6000 to 9000 >>> times during the processing of a Single Invoice - since there are >>> MULTIPLE references in the existing code where the Shipment Amount >>> > for > >>> >>> >> a >> >> >>> line must be calculated)? >>> >>> >>> >>> I guess I could create a temporary IDX file to help me Index the >>> >>> >> Cursor >> >> >>> (and - no - I've never done that - but, am just assuming it can be >>> done)! >>> >>> >>> >>> Or - should I just make this thing a Temporary DBF with a Temp Index >>> > - > >>> and just forget the idea of a Cursor for this situation??? >>> >>> >>> >>> Sorry about the lengthy explanation - which I hope makes sense... >>> >>> >>> >>> Thanks, >>> >>> -K- >>> >>> >>> >>> Developer >>> >>> Mr. Software of East Coast, Inc. >>> >>> Division of Waitex Information System, Inc. >>> >>> >>> >>> >>> >>> --- StripMime Report -- processed MIME parts --- >>> multipart/alternative >>> text/plain (text body -- kept) >>> text/html >>> --- >>> >>> >>> [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
