Re: SYSCOLUMNS & SYSCOLUMN2

Comments in-line John.

On Nov 25, 2019, at 5:58 PM, John Yeung <gallium.arsenide@xxxxxxxxx> wrote:

I notice that if you have a date in a table that the reported length is 4 - which while technically accurate is fundamentally useless as a program can never see it as that length.

I disagree with you on the "fundamentally useless" part. It could be
useful to know how much raw storage something takes up, and in the
past I have been frustrated at not being able to get this information
easily.

I'm normally interested in the storage taken up by a row or the whole table. Not an individual field - but maybe you have a use for it.

<snip>

I will say that if it were up to me, I would not have the LENGTH of a
date "depend on the format" any more than the length of a numeric
field depends on commas or decimal points. I would accept an argument
for it always being 8 (with the rationale that a date is ultimately
numeric, and *ISO dates have 8 "human readable" digits) or always
being 10 (with the rationale that the string representation of an *ISO
date uses 10 printable characters).

But it DOES depend on the format. And I don't control that. If the date was defined as *MDY in the table (yes I know that is foolish but people do it) then in the program it occupies 8 bytes. If it is *ISO or *USA then it is 10 bytes.

Is there another table or a column in either SYSCOLUMNS or SYSCOLUMN2 that does accurately represent the size of the column or do I have to calculate it?

I am pretty sure you have to calculate it. But it's not hard. I think
what you are after is simply LENGTH(CHAR(my_date_field)).

Not quite that easy - remember i said it was a utility function - so the name of the field is not known at compile time.


Jon Paris