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

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.


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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.