Qdesign enhancement - Required Secondary file

[Joe Boyle]

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: 7726 bytes
Desc: not available
Url : http://lists.sowder.com/pipermail/powerh-l/attachments/20070612/38a6648a/winmail-0001.bin