Qdesign enhancement - Required Secondary file

[Joe Boyle]

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.


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 ) 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 7822 bytes
Desc: not available
Url : http://lists.sowder.com/pipermail/powerh-l/attachments/20070612/e016d8c6/winmail.bin