Qdesign enhancement - Required Secondary file

[Ken Langendock]

Sorry I meant combine the GENERAL-STOCK and SLIGHTLY_DAMAGED files into a
single CURSOR and treat that as a SECONDARY file.

I agree with you on the ISAM file structures.

Ken

> _____________________________________________ 
> From: 	Joe Boyle [mailto:atla38 at dsl.pipex.com] 
> Sent:	June 12, 2007 11:07 AM
> To:	'Ken Langendock'; powerh-l at lists.sowder.com
> Subject:	RE: Qdesign enhancement - Required Secondary file
> 
> It can be handled with cursors in a PH to RDB environment, but this isn't
> possible with b-tree type file systems e.g. RMS, DISAM, CISAM.... As for
> the option of putting the records in the same file, well often the data
> setup is in a legacy system where restructuring of this type isn't viable.
> 
> The suggestion below would have required the capability of providing some
> indication of where the in the find procedure to place the additional
> code. In the case below, the screen was clustered, with a repeating
> primary, so the extra code would have had to be placed in the 'for
> missing' loop of the find proc; I thought I would start at the bottom and
> work up this time; ah well, we can but try :-)
> 
> _____________________________________________
> 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 Ken Langendock
> Sent: 12 June 2007 13:01
> 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.
> 
>  << File: ATT00083.txt >> 
> 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 )  << OLE Object: Picture
> (Metafile) >> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 4022 bytes
Desc: not available
Url : http://lists.sowder.com/pipermail/powerh-l/attachments/20070612/f07c6ba6/winmail.bin