|
When you use SQL CURSOR you are reading the first of a set of conditions, in which you need not loop through them all. You can link that set of conditions to contents of other files that are relevant. I have RPG SQL programs with tons of different cursors defined in the same program for different conditions, scenarios. My cursors are never a single SQL statement. You have to open, access, close the cursor. I usually feed the data into a data structure, so the definition of the cursor is in the opening, and I can then access the cursor different places in the program. You have to be careful to sequence the subroutine nameing placement so that you do the open access close in that sequence. I have some RPG SQL in which 1. I do a count(*) which is also an EXIST check, then depending on what count(*) and error checking determines 2. Go after relevant data You can do SQL with WHERE some condition inside parentheses. I usually use if for JOIN NO_MATCH type stuff, such as list all inventory transactions on master controls that got deleted or no longer exist, or list all end items that are lacking a customer, but I guess you could use if count(*) is some result. We have similar scenario with items set aside for QC to take action, which sometimes get overlooked far too long. Plus, I been thinking about creating a report that identifies items that got their cost changed by more than a microscopic amount, since we typically find out considerable time later that costs need repairing, and in the meantime countless reports have been contaminated. Depending on how you navigate your transaction history, you might have like in our item master file there is a counter of transaction hits which connects to a record # in the transaction history file ... record # 1 on any item being the *FIRST entry of that item in the transaction history. We have logical access to transaction history, such that the *FIRST entry for an item is relevant to your interest. You can create a JOIN LOGICAL but the keys have all got to be from ONE of the files. If you then run that file as part of the input to an OPNQRYF you can key that on fields from several files. Depending on how you manage your transaction history, there may be items inactive for longer time period than the history is retained. When we did our last major BPCS upgrade we lost the ability to keep the last *N records on inactive items (a case of some negative enhancements mixed in with positive ones) While it might make sense for this to run each evening, after everyone done for the day, using *CURRENT date, when people working late, and JOBQ backed up, you might be better off having GO CMDSCDE launch it at 1 am, and have it look for *CURRENT date minus one *DAY. Perhaps you could put a trigger on the item master file, to catch when the date of last receipt field goes from zero or null contents to valid ISO date. We also have some change history applications where each evening 1. Compare current data with prior story, and generate a change record when changed. You gotta be careful in design to allow for deletions, otherwise comparing record for record current data vs. old story will only catch additions and changes, not deletions. 2. Replace prior story for the fields we are comparing. All, I've written 1 RPG SQL program in the past and have come upon a report project that I think would benefit from SQL, but I need help. What I want is, at the end of the day, print a report for the warehouse of every item that was received for the very first time that day. (The report is for the warehouse to examine the item for HazMat. Yes, they could do it when physically receiving the product, but some are getting missed. So we're going to make it a separate task.) The item master file (DMITMMST) has a date of last receipt field (DTRCT) defined as 8,0 (I did some Y2K stuff before date fields existed). The receipt history file (DMRECHST) has 1 record for each receipt transaction and the receipt date in there is an *ISO date field. I could do this report by using this select: Select * From DBMSTF.DMITMMST Where DTRCT = 20060622 Order By WHSLC Then, in my RPG program, SETLL/READE the receipt history for each of these items, count how many receipt records there are, and if there's only 1, print the item. But I think I should be able to do the entire selection within an SQL statement. I know that a count(*) is probably involved in there somewhere. I searched the archives and found a lot with count(*), but nothing seemed comparable to what I'm trying. SQL scripting in iNav can really point out very quickly that you're in over your head. <g> Joining will be by item number which is ITNBR in the item master and RHITEM in receipt history. I also thought about the initial select against receipt history (since the receipt date is also in there), but the sort field I want is in the item master. And the item master has _far_ fewer records, so I thought the initial select against it would perform better. Is this doable in 1 SQL statement? Thanks. -- Jeff Crosby Dilgard Frozen Foods, Inc. P.O. Box 13369 Ft. Wayne, IN 46868-3369 260-422-7531 The opinions expressed are my own and not necessarily the opinion of my company. Unless I say so. -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.