Conference iosg::all-in-1_v30

I see that my first problem has already been NOTEd both here and in STARS,
sorry for shooting tooo fast on that one.

I couldn't, however, find any problem similar to the second problem that I
described. 

Is V3.0 more strict with ENTRY forms vis-a-vis the recorrd length as defined in
the .FDL file for the file and the total lengths of all the fields in the form.
At the time (7:30 pm since 7:00 am without any break) it didn't occur to me to
count and total all the field lengths of all the fields on the form to see if
that agrees with the length as defined in the .FDL file. This will have to wait
until Sunday when I return to the customer.

Any other ideas etc. will be appreciated...

Thanks,

Cb.

    re .1
    
    I don't have an answer I'm afraid, just some info to save you a
    wild-goose chase.
    
    ALL-IN-1 only uses the FDL file when initially creating the data file. 
    Once the file exists, ALL-IN-1 will never use or look at the FDL file,
    so you could change it (or even take it away, probably!) and ALL-IN-1
    wouldn't notice.  The record-length mis-match will be between the
    actual data file, and the entry form.
    
    Rather than counting field lengths on the entry form, you should be
    able to use GOLD-V to give you the information.
    
    Finally, are you sure that there is no new entry form in V3.0 with the
    same name as the customer's entry form?
    
    Scott

    ...and to add to Scott's answer (and state what you already know!)
    you could think about <CREATE  -ing a new data file, and doing a 
    data file conversion (oa$cnv_convert), when I think you will need
    a correctly defined .fdl. Use $analyse/rms/fdl to find the size.
    
    But as Scott says, look for an old entry form first.
    Hope this helps.
    DaveT

Re. .2:

>    ALL-IN-1 only uses the FDL file when initially creating the data file. 
>    Once the file exists, ALL-IN-1 will never use or look at the FDL file,
>    so you could change it (or even take it away, probably!) and ALL-IN-1
>    wouldn't notice.  

Is this true even when the file is indexed with secondary keys as well?

>    The record-length mis-match will be between the
>    actual data file, and the entry form.

In this case the file does match the record length as defined in the .FDL. I
have yet to check the actual form yet. Will be doing this later today.

>    
>    Rather than counting field lengths on the entry form, you should be
>    able to see GOLD-V to give you the information.

That's what I was planning on doing.

>    
>    Finally, are you sure that there is no new entry form in V3.0 with the
>    same name as the customer's entry form?
>    

The form being referrnced is the customers form, no doubts here.


Thanks,

Cb.

Problems are solved.

V3.0 is indeed much more strict with ENTRY forms vis-a-vis the actual data file
with regard to length. In the customer case, the data file itself showed fixed
length of 167 when totalling up the lengths of all the fields on the form came
to 168.

Thanks for all your help.

Cb.

    To tidy up the loose ends...
    
    >> Is this true even when the file is indexed with secondary keys as well?
    
    Yes.  ALL-IN-1 gets all the key information from the actual file, via
    key XABs.
    
    Scott