Conference ilbbak::ibi_focus

    Two suggestions + a solution :
    
    In your define statement, instead of using PN as the new field name why
    don't you use PART_NUMBER which I guess will override the original
    field.
    
    DEFINE FILE ...
    PART_NUMBER/A9=EDIT (PART_NUMBER,99-99999-99);
    END
    
    In relation to the second point (primary key), does it mind if you
    simply edit the .MAS file and delete the GROUP line.
    
    Last suggestion that could solve the user confusion but will make the
    process a bit heavier :
    let your .MAS file as it is now, define a new field as you have done it
    and then run a simple request which will store the information tailored
    as per your need in a new database :
    
    DEFINE FILE ...
    PN/A9=EDIT (PART_NUMBER,99-99999-99);
    END
    
    TABLE FILE ...
    PRINT PN AND XXX AND YYY        (let print what you see as typical
    				     record containing only the needed
    				     info)
    BY PN NOPRINT                   (take a sorting field followed by
    				     noprint since it is already menitonned
    				     in the first line).
    ON TABLE HOLD AS NEWDATABASE    (max 8 character for the name.
    				     Focus will generate the corresponding
    				     MAS file and store the info in a .FTM
    				     file).
    END
    
    VMS RENAME NEWDATABASE.FTM NEWDATABASE.DAT (when you exit focus,
    	normally are all .FTM files killed sothat you have to give another
    	extension if you want to keep it permanently).
    
    FILEDEF NEWDATABSE DISK NEWDATABASE.DAT
	The reference to the database is contained in the .MAS file.  If
    	you don't exit focus, at the time you were creating the .FTM
    	database, FOCUS has made a link (FILEDEF) to the .FTM file.  As
    	this last has been renamed, you have to recreate the link.  Note
    	that it is sufficient to exit focus and enter again to delete the
    	link to the .FTM file and by default, a new link with the database
    	will be created with the right extension.
    
    These explanations are only the reflect of my FOCUS understanding. 
    They are maybe too simplist, but I confirm you that it works.
    	
    Hoping this helps...

    Thanks for your response, but I'm afraid that the suggestions don't
    really help.
    
    >> In your define statement, instead of using PN as the new field name why
    >> don't you use PART_NUMBER which I guess will override the original
    >> field.
    
    Calling the new field PART_NUMBER instead of PN results in PART_NUMBER
    being displayed twice in the list of fields in TABLETALK. However,
    both PART_NUMBER fields are then displayed in the required 99-99999-99
    format, presumably because TABLETALK cannot differentiate between the 
    two fields. So, there is slight success but it is still confusing to 
    the users who see two fields called PART_NUMBER.
    
    >> In relation to the second point (primary key), does it mind if you
    >> simply edit the .MAS file and delete the GROUP line.
    
    Doing this results in the following error :-
    
    (FOC1087) ISAM FILE MUST HAVE PROPERLY DEFINED KEYS : SCPPT
    
    
    Chapter 3 , Section 6 ( on page 3-61 ) of the FOCUS Users Manual states 
    
    "RMS keyed fields may be described to FOCUS by supplying a SUFFIX of
    ISAM, and a new attribute,GROUP, to designate the primary key."
    
    and section 6.3 ( on the same page ) states "The primary key is defined
    to FOCUS by means of the GROUP attribute in the Master Description
    File. The GROUP declaration is followed by FIELD definitions for each
    of the fields that it comprises. ( The GROUP attribute must be used,
    even if only one FIELD is to be described for the GROUP )."
    
    >> Last suggestion that could solve the user confusion but will make the
    >> process a bit heavier :
    >> let your .MAS file as it is now, define a new field as you have done it
    >> and then run a simple request which will store the information tailored
    >> as per your need in a new database :
    
    I'm afraid that the third suggestion of reformatting the data into a
    new database entails too much of an overhead for a simple report
    formatting problem. 
    
    
    	Thanks anyway - any other suggestions from anyone ?
    
    		Terry
    
    

    What I would do is call the PART_NUMBER key field KEY_CODE,  
    DEFINE PART_NUMBER/A11 = EDIT(KEY_CODE,........),  and tell 
    the users to ignore the KEY_CODE field.