Qdesign enhancement - Required Secondary file

[Deskin, Bob]

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. 

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.

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.

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.

Bob

>  -----Original Message-----
> From: 	Ken Langendock [mailto:Ken at Langendock.com] 
> Sent:	June 12, 2007 8:01 AM
> To:	'Joe Boyle'; Deskin, Bob; powerh-l at lists.sowder.com
> Subject:	RE: Qdesign enhancement - Required Secondary file
> 
> Not to belittle your requirement, but could this not be done in a CURSOR in conjunction with the FILE REQUIRED option I am proposing?
> 
> Can the GENERAL-STOCK and SLIGHTLY_DAMAGED files can be combined into a single SECONDARY file?
> 
> Ken
> 
> _____________________________________________ 
> From: 	Joe Boyle [mailto:atla38 at dsl.pipex.com] 
> Sent:	June 12, 2007 5:50 AM
> To:	'Deskin, Bob'; 'Ken Langendock'; powerh-l at lists.sowder.com
> Subject:	RE: Qdesign enhancement - Required Secondary file
> 
> Well, if you are going to ask for something, you might as well start at the summit and work your way down :-)
> 
> 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.
> 
> 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.
> 
> E.g below,
> 
> 		file Primary stock_code
> 
> 		file secondary general_stock                  
> 
> 		file secondary slightly_damaged            
> 
> 		file secondary fail_file
> 		access via> ...> 
> 		select if 1 = 2
> 
> 
> 		Proc appendfind 
> 
> 		If not accessok of general_stock and not accessok of slightly_damaged           
> 		Then get fail_file
> 
> 		end          
> 
> 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.
> 
>  << OLE Object: Picture (Metafile) >> 
> From: powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com [mailto:powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com] On Behalf Of Deskin, Bob
> Sent: 11 June 2007 15:01
> To: Joe Boyle; Ken Langendock; powerh-l at lists.sowder.com
> Subject: RE: Qdesign enhancement - Required Secondary file
> 
> 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).> 
>  
> 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.
>  
> 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.
>  
> But please don't stop suggesting.
>  
> Bob
>  
>  
> SNIP ( exceeded the size limit for the list )
 
     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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sowder.com/pipermail/powerh-l/attachments/20070612/e08b75f7/attachment.html