×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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.
However, I fully agree with you that LENGTH is not the place for this
information. The right place is the STORAGE column. For example, an
8-digit packed field and an 8-digit zoned field both have LENGTH 8,
but the packed field has STORAGE 5 while the zoned has 8. So I think
having STORAGE be 4 for a date field is correct, but the LENGTH should
be something else.
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).
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)).
John Y.
midrange.com
