× 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.



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.

It sounded like you wanted to look at things from an SQL point of view
(you mentioned "table" rather than "file" for example). From that
point of view, a date is a date is a date. My understanding is that
there isn't such a thing as defining a date format *in the table*,
even though you can do it in a file with DDS.

Of course, I think it would be conceptually possible for IBM to
provide more SQL exposure to DDS-specific features, but so far I don't
think they've done it for this, and I wouldn't expect them to.

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.

What does being utility software have to do with anything? One of the
benefits of using SQL is that you have the flexibility to introspect
and compose at run time. That actually strikes me as one of the
primary purposes of SYSCOLUMNS in the first place.

John Y.

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-2024 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.