<HTML >
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: Qdesign enhancement - Required Secondary file</TITLE>
</HEAD>
<BODY >
<DIV>
<!-- Converted from text/rtf format -->
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">In thinking back (and by back I mean the mid 80s) to some of the procedure requests and what we have done, we found that simply adding code at the beginning or end of a procedure was rarely enough. What we tried to do is have procedures that actually added processing to points in the cycle where you couldn't get to otherwise. </FONT></P>
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">So if you look at our PRE and POST procedures, in most cases they are specific points in the processing flow where simply adding code to the beginning or end of another procedure would not have the same effect. Also, the PRE and POST procedures are not included in the error backup process of the main procedure.</FONT></P>
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">The suggested PREPROMPT/PREINPUT procedure is a point in the flow where you can't get to without adding to the ENTRY procedure. It takes place after the start of the ACCEPT cycle just before the user prompt. The suggested PREDELETE procedure lets you condition the DELETE and that can't be done at this time. PREAPPEND is probably another good candidate.</FONT></P>
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">As for the REQUIRED on SECONDARY files, it's a reasonable extension even though if won't handle the conditional cases. Conditional cases are why we have procedure code. As Rick Soderstrom (the creator of QUICK) once told me: "if we were smart enough, we wouldn't need procedure code". What he meant was that if we could determine all of the possible uses and make those into non-procedural specification syntax, then we wouldn't need procedure code.</FONT></P>
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Bob</FONT>
</P>
<UL>
<P><FONT FACE="Arial"><SPAN LANG="en-us"></SPAN></FONT><SPAN LANG="en-us"> <FONT SIZE=1 FACE="Tahoma">-----Original Message-----</FONT></SPAN>
<BR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">From: </FONT></B> <FONT SIZE=1 FACE="Tahoma">Ken Langendock [</FONT></SPAN><A HREF="mailto:Ken@Langendock.com"><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" SIZE=1 FACE="Tahoma">mailto:Ken@Langendock.com</FONT></U></SPAN></A><SPAN LANG="en-us"><FONT SIZE=1 FACE="Tahoma">] </FONT></SPAN>
<BR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">Sent: </FONT></B> <FONT SIZE=1 FACE="Tahoma">June 12, 2007 8:01 AM</FONT></SPAN>
<BR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">To: </FONT></B> <FONT SIZE=1 FACE="Tahoma">'Joe Boyle'; Deskin, Bob; powerh-l@lists.sowder.com</FONT></SPAN>
<BR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">Subject: </FONT></B> <FONT SIZE=1 FACE="Tahoma">RE: Qdesign enhancement - Required Secondary file</FONT></SPAN>
</P>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Not to belittle your requirement, but could this not be done in a CURSOR in conjunction with the FILE REQUIRED option I am proposing?</FONT></SPAN></P>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Can the GENERAL-STOCK and SLIGHTLY_DAMAGED files can be combined into a single SECONDARY file?</FONT></SPAN>
</P>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Ken</FONT></SPAN>
</P>
<P><SPAN LANG="en-ca"><FONT SIZE=1 FACE="Tahoma">_____________________________________________ </FONT></SPAN>
<BR><SPAN LANG="en-ca"><B><FONT SIZE=1 FACE="Tahoma">From: </FONT></B> <FONT SIZE=1 FACE="Tahoma">Joe Boyle [</FONT></SPAN><A HREF="mailto:atla38@dsl.pipex.com"><SPAN LANG="en-ca"><U><FONT COLOR="#0000FF" SIZE=1 FACE="Tahoma">mailto:atla38@dsl.pipex.com</FONT></U></SPAN></A><SPAN LANG="en-ca"><FONT SIZE=1 FACE="Tahoma">] </FONT></SPAN>
<BR><SPAN LANG="en-ca"><B><FONT SIZE=1 FACE="Tahoma">Sent: </FONT></B> <FONT SIZE=1 FACE="Tahoma">June 12, 2007 5:50 AM</FONT></SPAN>
<BR><SPAN LANG="en-ca"><B><FONT SIZE=1 FACE="Tahoma">To: </FONT></B> <FONT SIZE=1 FACE="Tahoma">'Deskin, Bob'; 'Ken Langendock'; powerh-l@lists.sowder.com</FONT></SPAN>
<BR><SPAN LANG="en-ca"><B><FONT SIZE=1 FACE="Tahoma">Subject: </FONT></B> <FONT SIZE=1 FACE="Tahoma">RE: Qdesign enhancement - Required Secondary file</FONT></SPAN>
</P>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" FACE="Arial">Well, if you are going to ask for something, you might as well start at the summit and work your way down</FONT> <FONT COLOR="#0000FF" FACE="Wingdings">J</FONT></SPAN>
</P>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" FACE="Arial">Ok, how about adding ( and this is not one of my jokes ) a appendfind procedure, where code can be inserted that will then be appended to the find procedure before it is parsed.</FONT></SPAN></P>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" FACE="Arial">Ken’s requirement is a means of avoiding a recode of the entire find procedure when all you want to do is make the primary read dependant on the existence of it’s secondary. I agree with this requirement but suspect that the more likely case will be that the primary read is dependant on the existence of a number of its secondary’s. If Ken’s request goes through as is, I can see that there will be almost as much find proc rewriting as there is now.</FONT></SPAN></P>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" FACE="Arial">E.g below,</FONT></SPAN>
</P>
<UL><UL>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" FACE="Arial">file Primary stock_code</FONT></SPAN>
</P>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" FACE="Arial">file secondary general_stock                  </FONT></SPAN>
</P>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" FACE="Arial">file secondary slightly_damaged            </FONT></SPAN>
</P>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" FACE="Arial">file secondary fail_file</FONT></SPAN>
<BR><SPAN LANG="en-gb"><FONT COLOR="#0000FF" FACE="Arial">access via…</FONT></SPAN>
<BR><SPAN LANG="en-gb"><FONT COLOR="#0000FF" FACE="Arial">select if 1 = 2</FONT></SPAN>
</P>
<BR>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" FACE="Arial">Proc appendfind </FONT></SPAN>
</P>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" FACE="Arial">If not accessok of general_stock and not accessok of slightly_damaged           </FONT></SPAN>
<BR><SPAN LANG="en-gb"><FONT COLOR="#0000FF" FACE="Arial">Then get fail_file</FONT></SPAN>
</P>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" FACE="Arial">end          </FONT></SPAN>
</P>
</UL></UL>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" FACE="Arial">I suspect that a new form of accessok flag might be needed that would indicate if the buffer of a named file was read in at the last attempt.</FONT></SPAN></P>
<P><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> << OLE Object: Picture (Metafile) >></FONT> </SPAN>
<BR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="Tahoma">From:</FONT></B><FONT SIZE=2 FACE="Tahoma"> powerh-l-bounces+atla38=dsl.pipex.com@lists.sowder.com [</FONT></SPAN><A HREF="mailto:powerh-l-bounces+atla38=dsl.pipex.com@lists.sowder.com"><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma">mailto:powerh-l-bounces+atla38=dsl.pipex.com@lists.sowder.com</FONT></U></SPAN></A><SPAN LANG="en-us"><FONT SIZE=2 FACE="Tahoma">]</FONT><B> <FONT SIZE=2 FACE="Tahoma">On Behalf Of</FONT></B> <FONT SIZE=2 FACE="Tahoma">Deskin, Bob<BR>
</FONT><B><FONT SIZE=2 FACE="Tahoma">Sent:</FONT></B><FONT SIZE=2 FACE="Tahoma"> 11 June 2007 15:01<BR>
</FONT><B><FONT SIZE=2 FACE="Tahoma">To:</FONT></B><FONT SIZE=2 FACE="Tahoma"> Joe Boyle; Ken Langendock; powerh-l@lists.sowder.com<BR>
</FONT><B><FONT SIZE=2 FACE="Tahoma">Subject:</FONT></B><FONT SIZE=2 FACE="Tahoma"> RE: Qdesign enhancement - Required Secondary file</FONT></SPAN>
</P>
<P><SPAN LANG="en-gb"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">To be honest, I think this is the realm of the developer as opposed to the language. Feel free to disagree with me (everyone, not just Joe).</FONT></SPAN></P>
<P><SPAN LANG="en-gb"><FONT FACE="Times New Roman"> </FONT></SPAN>
<BR><SPAN LANG="en-gb"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Be default, an error in the FIND procedure backs up to a previous GET for the PRIMARY. If a SECONDARY is REQUIRED, the PRIMARY-SECONDARY pair becomes required rather than just the PRIMARY. If the SECONDARY retrieval fails (an error if REQUIRED), then the process backs up and does the PRIMARY GET to retrieve the next record/row.</FONT></SPAN></P>
<P><SPAN LANG="en-gb"><FONT FACE="Times New Roman"> </FONT></SPAN>
<BR><SPAN LANG="en-gb"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">For something like you describe, I suggest that we're into the area of the developer coding his/her own FIND using GET OPTIONAL on the SECONDARY files and doing the appropriate logic. I believe that there are many other possible complexities other than did the record get retrieved. So while we might be able to add something, I doubt it would rank very high in the priority list.</FONT></SPAN></P>
<P><SPAN LANG="en-gb"><FONT FACE="Times New Roman"> </FONT></SPAN>
<BR><SPAN LANG="en-gb"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">But please don't stop suggesting.</FONT></SPAN>
<BR><SPAN LANG="en-gb"><FONT FACE="Times New Roman"> </FONT></SPAN>
<BR><SPAN LANG="en-gb"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Bob</FONT></SPAN>
<BR><SPAN LANG="en-gb"><FONT FACE="Times New Roman"> </FONT></SPAN>
<BR><SPAN LANG="en-gb"><FONT FACE="Times New Roman"> </FONT></SPAN>
<BR><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma">SNIP ( exceeded the size limit for the list )</FONT></SPAN><SPAN LANG="en-gb"></SPAN><SPAN LANG="en-gb"></SPAN><SPAN LANG="en-gb"><FONT FACE="Times New Roman"> </FONT></SPAN>
</P>
</UL>
</DIV>
<DIV> </DIV>
<DIV> This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you. </DIV></BODY></HTML>