Conference iosg::all-in-1_v30

It's a known problem, but I don't think it was introduced in V3.0-1.

The problem occurs because the file cabinet information for the format 
field (.DFORMAT) is corrupted.  Probably the field was originally blank, 
with the Data type set to WPSPLUS.  When the document is restored the 
.DFORMAT field is set to a random value. 

When the document is printed a blank .DFORMAT field will cause the
formatting to be derived from the Data type, which will be WPS-PLUS.
However, the .DFORMAT field is not blank so the print sub-system goes to
get information from the FORMAT master.  Because the record doesn't exist
all fields will be returned as blank and the print sub-system will fall
back to doing ASCII formatting. 

The .WPL file for the attachment should be intact, and still contain all
the WPS-PLUS Print Settings, so the user should be able to detach it and
reset the handling field. 


Richard

    
    Hi Richard
    
    I've looked at the attributes of the attachment in both archived
    messages and non-archived messages, and the DFORMAT field seems to
    disappear!
    
    For the non-archived document, if I use 
    
    <for cab$attach do for cab$attach_attributes do get .key " : " .value
    
    This gives me a list of the fields and their values like:
    
    DCREATED : 31-Jul-1992 01:56pm
    DFORMAT : 
    DMODIFIED : 20-Apr-1993 09:55am
    
    but if I do exactly the same thing on a message which has got an
    attachment and has been archived and restored, I get this:
    
    DCREATED : 31-Jul-1992 01:56pm
    DMODIFIED : 20-Apr-1993 09:55am
    
    The DFORMAT field isn't there anymore, so I can't check the value which
    is stored there.
    
    Any ideas? The customer noticed this when they were transferring users,
    as this archives the users document, all of the transferred users are
    seeing this problem, and detaching each attachment is something which
    the customer is not willing to do at this time.
    
    Steve.
    

    
    Well, I've read the suggestion made in 1185.3 and teseted the
    workaround suggested (see below) and thats fine for ALL-IN-1 3.0
    systems.
     
    What the customer didn't tell me is that they've also got the problem
    on their 2.4 system. The 3.0 system is their test system in preparation
    for the big upgrade which will not be taking place in the near future.
    In the mean time, they have got a few hundred users who were
    transferred (which is where they origionally saw the problem) who have
    got 'broken' attachments.
    
    Can anyone out there think of a way of implementing the check
    
    .if fn$length(#PRINT_FORMAT) eq 1 then get #PRINT_FORMAT = ""
    
    (or something similar) in ALL-IN-1 2.4?
    
    Thanx
    
    Steve.
    

    Hi,
    
    Not so elegant but how about:
    
    .if #PRINT_FORMAT::1 eqs "" then get #PRINT_FORMAT = ""
    
    HTH
    
    Stuart