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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2022 by midrange.com 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.