Re: outdisk/fits

[Michel Laget <mlaget@free.fr>]

Hi to all of you and thanks for the answers.

I did realize indeed that deleting selidx could solve the problem but
because I am not aware of the full functionality of this descriptor, i
could *not* explain 1)- that deleting the desc could result in unseen
errors and 2) why this very  descriptor does not seem as critical at all
(with the same table...) on 99NOVpl2.0 OSF_axp, thouh also present in
the tables. 

Also, one of the trick is that until one uses outdisk or want to see
that very descriptor the table behaves correctly. 

The key role of outdisk/fits (often run in automated scripts) in
back-ups make the issue critical as, pointed out, onto whether to warn
the user.  

Thank you very much,

Michel Laget



Sebastian Jester a écrit :
> 
> Hi,
> 
>  Klaus Banse wrote:
> 
> > P.S. That leaves us with the question of what to do with such a huge SELIDX
> > descriptor resulting automatically from the SELECT/TABLE command.
> > Since the logical expression in that command can fill up all paramters
> > P2, ..., P8 there is no "space" for a YES/NO flag for the descr. creation.
> > Should we just put in a limit of, say, 100 000 elements or leave it to the
> > discretion of the user to later on delete that descr. if it's not needed?
> 
> I would very strongly argue against any explicit or implicit limitation on
> table or descriptor size. Somebody may want to work with SELIDX, whatever its
> length (it has to have a purpose). As the problem occurs when the many
> descriptor elements are converted to FITS header lines, OUTDISK/FITS would be
> the place to check whether a descriptor is longer than a certain limit, issue
> a warning that this will take lots of time and space to write out as .fits
> file, and ask the user what to do. If she doesn't want all the descriptor
> elements saved in the fits file, she can still delete by hand.
> 
> IMHO, it is best just to make the user aware of this circumstance and let
> everyone decide what to do about it, rather than guessing what might be best
> and leaving no choice.
> 
> Regards,
> 
> Sebastian Jester

begin:vcard 
n:Laget;Michel
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:mlaget@free.fr
note;quoted-printable:michel.laget@astrsp-mrs.fr=0D=0Amlaget@free.fr=0D=0A=0D=0A33 (0)491 055931 (lab)=0D=0A33 (0)491 611504 (home)=0D=0A33 (0)491 611504 (fax)
x-mozilla-cpt:;2176
fn:Michel Laget
end:vcard