[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Author Index][Subject Index]
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
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
Thank you very much,
Sebastian Jester a écrit :
> 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.
> Sebastian Jester
note;quoted-printable:email@example.com=0D=0Amlaget@free.fr=0D=0A=0D=0A33 (0)491 055931 (lab)=0D=0A33 (0)491 611504 (home)=0D=0A33 (0)491 611504 (fax)